🚀 go-pugleaf

In article <1992Dec20.022054@avsht.sph.spb.su> avsht@sph.spb.su wrote:
>Suppose I got a forwarded letter. The original letter
>had the header "Return-Receipt-To", so the target system
>has already generated and sent notifying mail.
>Neverthenless this header came to my system as well.
>Should my mailer send one more notifying message to the
>author?

I believe that it should not do so (I was once bombarded by return receipts
after sending a bug report to one of FSF's bug-reporting addresses, which
expanded to a mailing list).

In the case of a message being manually forwarded, the forwarder should
probably delete the Return-Receipt-To header.

There are also a few ways that the message can be automatically forwarded to
another system:
1)	via an alias expansion
2)	via a sendmail .forward file
3)	by expansion into a mailing list (this is often a special case of
	alias expansion)

In the case of automatic forwarding I'm not sure, however what the best approach is:
a)	if forwarding, don't send a return receipt; defer that to the system
	performing final delivery
b)	send the return receipt, but delete the Return-Receipt-To header
	before forwarding.

>References to standards (RFCs?) will be very useful.

There aren't any--Return-Receipt-To has not been standardized (to my
knowledge), but is hard-coded into sendmail.

[Followups directed to comp.mail.sendmail]
-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce

Return-Receipt-To is a kluge and a hack invented and first used by the
abominable sendmail program for BSD Unix.  It is not standardized,
neither as a header, nor as functionality.  No one has bothered to write
up a specification for it and submitted it as an RFC.  It's generally
considered a Bad Thing because (1) not all mailers implement it, so
absence of a returned receipt means nothing, and mail is not 100%
reliable, anyway, so even if a receipt is generated, it may not get back
to you, especially if headers get rewritten and the address in the
header is useless where generated, (2) it's often used indiscriminately
by those who use it all, causing much wasted bandwidth, and (3) it gives
users the impression that they can get a service that doesn't exist in
the Internet mail system.

'Tis best to ignore it entirely.

An argument could be put forth that it should be deleted, but this
requires some level of recognition of it, which is almost as bad as
responding positively to it.

Let's hope that 1993 will see a replacement for sendmail, and wide
deployment of real MTA software, to support 8-bit data paths, MIME, etc.
I might as well hope for the demise of X.400 while I'm at it.

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
                            ISO 10744 HyTime
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis

In article <19921225.001@erik.naggum.no>, erik@naggum.no (Erik Naggum)
wrote:
> No one has bothered to write
> up a specification for it and submitted it as an RFC.

I think it is high time that some form of standard return receipt were
available in Internet mail.  It's one of the few functional areas where the
Internet lags behind practically ever proprietary mail system, and X.400 to
boot.

Suppose one were contemplating writing such an RFC (one is in fact
contemplating exactly that :-)).  What should it be?  Bear in mind that it
must be practical to implement and provide some useful amount of function.

My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
successful delivery, since it has some utility and is also not going to go
away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
ONLY the MUA) when the message is actually read.

Let me enumerate some of the objections I've heard to this type of feature,
and rebut them:

Delivery receipts:

Objection 1.  Since not every mail system implements it, it's meaningless. 
Failing to receive the receipt does not mean the message was not delivered.
Rebuttal 1.  While it is true that the negative is of questionable value,
the positive does indeed mean something.  And, in the scope of a local
authority, it's quite possible to make the negative mean something, too.

Objection 2.  Where do you draw the line at what is "final" delivery?  What
about POP and POP-like systems?
Rebuttal 2.  Who cares?  :-)  You do at least know that the message was
delivered to some maildrop.  It's better than nothing.

Objection 3.  Bandwidth.  Return receipts would eat the Internet alive.
Rebuttal 3.  The annoyance factor to the receipt-ee is high enough that I
don't personally feel this is a problem.

Read receipts:

Objection 1.  See above.
Rebuttal 1. See above.

Objection 2. See above, but replace '"final" delivery' with '"really"
read'.
Rebuttal 2. See above, but replace 'delivered to some maildrop' with
'examined by the user or some direct agent of the user'.

Objection 3. See above.
Rebuttal 3. See above.

Objection 4. It's none of your business when or if I read my mail.
Rebuttal 4. MUA's can provide you the option of suppressing read-receipts,
if you're paranoid.  This lessens the meaning of a negative, but again
leaves the positive unsullied.

Objection 5. A user-generated reply is the best return receipt.
Rebuttal 5. True.  But why not automate the process for the recipient's
benefit?  I would be perfectly happy if my MUA could acknowledge things for
me, so I could then get around to them in my own good time without seeing
repeated "Did you get my message?" queries.

Objection 6. Various quibbles about exactly what the US Postal Service does
or does not mean by or do with a return receipt, and various arguments
about how they could or could not be implemented in the Internet.
Rebuttal 6. Who cares?  If we wanted to emulate the USPS exactly, we'd
build a random mail misdirection system, and intentionally rude and stupid
MTA's.  (Comments about sendmail not invited :-).)
--
Steve Dorner, Qualcomm, Inc.

sdorner@qualcomm.com (Steve Dorner) writes:

>I think it is high time that some form of standard return receipt were
>available in Internet mail.  It's one of the few functional areas where the
>Internet lags behind practically ever proprietary mail system, and X.400 to
>boot.

>My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
>successful delivery, since it has some utility and is also not going to go
>away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
>would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
>ONLY the MUA) when the message is actually read.
>--
>Steve Dorner, Qualcomm, Inc.

   I would tend to agree with your leaning, but several SMTP compatible
mail packages already implement "Return-Receipt-To:" as a read
receipt (Control Data's ASCENT*Mail is one of these and is widely
used in the U.S. Air Force).  I had the pleasure of hacking "elm"
to recognize and implement this header for an Air Force customer
who demanded this capability and desired compatibility with
existing systems.

  My recommendation on this subject however, would not be to
try to formalize the "Return-Receipt-To:" header (or create
a Read-Receipt-Header), but instead to attempt to take advantages
of MIME, which is now gaining rapid popularity.  By using MIME's
content type/subtype classifications similar to "message/external-body",
one could implement read receipts at the MUA level as you suggested,
but probably with much greater ease.  A good example of how
this could be done is the MIME compliant messages sent out by
the IETF announcing new/proposed RFC's.  When these messages are
read with a MIME compliant reader, the user is given the opportunity
to automatically send a request to a mail server.

  Although metamail's "showexternal" script is not ideally suited
to read receipts, perhaps a new MIME subcontent type definition
(and accompanying metamail script for MIME readers using metamail) i
would allow the easiest and most elegant implementation of read receipts.

--
Kevin M. Hanrahan            hanrahan@wpsp01.hq.aflc.af.mil
C.E.T.A. Corporation
Beavercreek, OH              (513) 427-CETA            

I apologize for the length, but this is something I feel fairly
strongly about.  Sprinkle liberally with IMHOs.

My position on this is that receipts are only genuinely useful if they
are guaranteed.  Since we can't get this with the loose email net we
have, it's not useful.

With return-receipt-to, a lack of response means nothing (your message
may or may not have been delivered), and a positive response means
there's a good chance your message was delivered, but it's my no means
foolproof.  So if you really care, you'll ask the recipient for some
response, and eventually resort to telephone.  If you only would like
some indication but it's not critical, ie. return-receipt-to would do,
wouldn't a bounce also do?  It's only slightly more likely if at all
that you won't get a bounce if the mail isn't delivered but would get a
return-receipt-to.

With read receipts the same scenario applies.  If you care, an
automated response is not enough, and if you don't care, why bother?
If you want to make it easier for recipients, add a feature to send a
short acknowledgement message to selected or all mail items.

|My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
|successful delivery, since it has some utility and is also not going to go
|away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
|would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
|ONLY the MUA) when the message is actually read.

If you do this, please stress in the RFC that a lack of response
doesn't indicate anything, and that a positive response may not mean
what you think, ie. a return response means that some MTA somewhere
thinks they've probably delivered the message to something, which may
or may not have discarded, lost or resent it, and a read response
means that something that thought it was a mail reader was somehow
invoked and may or may not have presented the mail to someone who may
or may have not been the recipient.

User expectation is perhaps the biggest problem.  As a side story, I
used to work at a place where the admin staff used a "friendly" mailer
that had read receipts.  One user got very confused because she would
get replies to her mail, and a day or so later get told by the
friendly mailer that the recipient had not yet read the mail, even
though she'd seen the reply.  When the cause was explained, she
couldn't see the point of the read receipt feature because she was
expecting something more meaningful.

|Objection 1.  Since not every mail system implements it, it's meaningless. 
|Failing to receive the receipt does not mean the message was not delivered.
|Rebuttal 1.  While it is true that the negative is of questionable value,
|the positive does indeed mean something.

But not much, see above.

|And, in the scope of a local
|authority, it's quite possible to make the negative mean something, too.

In a local authority, there's no need for a standard, and you would
probably want something much tighter than a standard could be, so that
negative responses definitely meant something.

Again remember that even in a local authority trying to do this, lack
of response does not necessarily indicate the original message was not
delivered/read; the response could have been lost.

|Objection 2.  Where do you draw the line at what is "final" delivery?  What
|about POP and POP-like systems?
|Rebuttal 2.  Who cares?  :-)  You do at least know that the message was
|delivered to some maildrop.  It's better than nothing.

I don't really buy this last claim.  If it's not at the honest to
goodness last stop, it's not any more useful than if the sending MTA
responded, saying, "well, it's on it's way".  Perhaps it is better
than nothing but not by any valuable amount.

|Objection 3.  Bandwidth.  Return receipts would eat the Internet alive.
|Rebuttal 3.  The annoyance factor to the receipt-ee is high enough that I
|don't personally feel this is a problem.

Well, if they're automatically matched to the outgoing mail, the
annoyance factor is low so that won't help, but I feel bandwidth isn't
a big problem anyway.

|Read receipts:
|
|[...]
|
|Objection 4. It's none of your business when or if I read my mail.
|Rebuttal 4. MUA's can provide you the option of suppressing read-receipts,
|if you're paranoid.  This lessens the meaning of a negative, but again
|leaves the positive unsullied.

I don't think it's a matter of paranoid.  Thinking I've read my mail
may create some sort of expectation in the sender's mind.  For example
if you sent me a long piece of mail that I received just before I was
to go on vacation, and I looked at it (generating a read receipt),
decided I didn't have time to deal with it, and left.  Now I never got
to the part that says "If you can't do this by Tuesday, let me know so
I can make alternate arrangements".  You think I've read the message,
but I don't follow up telling you I can't do it.

In article <sdorner-271292095054@0.0.0.0> sdorner@qualcomm.com (Steve Dorner) writes:

>I think it is high time that some form of standard return receipt were
>available in Internet mail.  It's one of the few functional areas where the
>Internet lags behind practically ever proprietary mail system, and X.400 to
>boot.
>
>Suppose one were contemplating writing such an RFC (one is in fact
>contemplating exactly that :-)).  What should it be?  Bear in mind that it
>must be practical to implement and provide some useful amount of function.

How about picking one of the existing formats for a change?  As you
mentioned, it's already being done.

>My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
>successful delivery, since it has some utility and is also not going to go
>away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
>would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
>ONLY the MUA) when the message is actually read.

The real problem with both of these is that they necessarily apply to
all recipients, where you may want a receipt from only one or a few.

The AT&T PMX-mailers add "/receipt" to specific To: or CC: lines to
request receipts individually.  The receiving program may not
recognize the name in the address due to aliasing or forwarding, so
the sending side provides another header ">To: address  /receipt" on
each copy where the receipt was requested.  The PMX-mailers are
pretty dumb about this and make a separate copy for each To: or CC:
line in the message, but a smarter approach would be to make just
the number of copies you need (1 if all addresses are the same, 2
if some request receipts and some don't).  Of course you could use
Read-Receipt-Requested: this way too.

>Objection 2.  Where do you draw the line at what is "final" delivery?  What
>about POP and POP-like systems?

The AT&T packages that are more or less "on-line" and able to send at any
time generate the receipt when the message is displayed on the screen
(that is, the user selects "read").  The dial-up versions (access-plus
and the windows and mac equivalents) generate the receipts as the messages
are transferred out to the remote machine since they will be off-line
as they are read.  The wording of the receipt is different to indicate
the condition.

>Objection 3.  Bandwidth.  Return receipts would eat the Internet alive.
>Rebuttal 3.  The annoyance factor to the receipt-ee is high enough that I
>don't personally feel this is a problem.

More to the point, it saves a phone call, and if you have to call to
check on the email, why bother with the email in the first place?

>Objection 4. It's none of your business when or if I read my mail.
>Rebuttal 4. MUA's can provide you the option of suppressing read-receipts,
>if you're paranoid.  This lessens the meaning of a negative, but again
>leaves the positive unsullied.

And then you're back to the phone calls.  Unless you only use
email for things that don't matter.  So why bother?

Les Mikesell
  les@chinet.chi.il.us

The biggest question about Return-Receipt-To: is what to do when a
nieve user sends mail to a mailing list with this header in it.  It
would generate TONES of automatic messages w/o much usefulness to the
user that set Return-Receipt-To: on by default.  It would be critical
that mailing lists and such filter out Return-Receipt-To:.  Also, it
should be expressly forbidden to have a Return-Receipt-To: on a return
receipt, for obvious reasons.

Return-Receipt-To is a dangerous header as it stands now.  If its use
is to be standardized, its meaning much change :-)

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

In article <1992Dec28.171751.25819@chance.gts.org>, john@chance.gts.org
(John R MacMillan) wrote:
> With return-receipt-to, a lack of response means nothing (your message
> may or may not have been delivered), and a positive response means
> there's a good chance your message was delivered, but it's my no means
> foolproof.

The positive response tells me that there is a path to and from my
addressee.  Yes, there may be bizarre gateway software that fools the
scheme; but I don't think that's all that common anymore, and it's becoming
less so.

> With read receipts the same scenario applies.  If you care, an
> automated response is not enough, and if you don't care, why bother?

That depends on what the purpose of the receipt is.  If the purpose is "If
you don't press the blue button in the next 30 seconds we're all going to
die," you're right.  However, if I want some degree of proof that my
question reached Marshall Rose, it's a different story.

> In a local authority, there's no need for a standard

This is quite entirely wrong, no IMHO about it.  :-)  Even in a local
authority, there is software that needs to interoperate, which means
standards are needed.

> probably want something much tighter than a standard could be, so that
> negative responses definitely meant something.

But if I can guarantee the integrity of my mailsystem at a given point in
time, then I have made negative responses mean something.  I think that's
doable 99.9% of the time in a small-to-medium-sized domain.  I at least
want the opportunity to try, which the lack of standards prevents me from
having.

I can certainly understand the objections.  However, people are using the
non-standard tools we now have (like Return-Receipt-To:), and they seem to
feel it's worthwhile.  Better to have a standard way of doing this, even if
we acknowledge we cannot yet perfectly implement it.
--
Steve Dorner, Qualcomm, Inc.

sdorner@qualcomm.com (Steve Dorner) writes:
|I think it is high time that some form of standard return receipt were
|available in Internet mail.  It's one of the few functional areas where the
|Internet lags behind practically ever proprietary mail system, and X.400 to
|boot.

 Well, the historical reason this wasn't necessary/desirable/done is
called finger.   For those machines which supported the smtp and finger
protocols, one could usually discover if the recipient had undelivered
mail, or whether she had read it.

 Sendmail added return reciepts, but primarily for working through gateways...

  I regularly finger people, then look to see when my message was sent.
Result? I know if it was read.
 I already **know** it was delivered: I didn't get a ``599 mail undeliverable:
recipient had moved to mars'' message.

--dave

-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York Postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.

In article <291@ima.com> kehres@ima.com (Tim Kehres) writes:
>One area that seems to generate a lot of concern is when it comes to UA's 
>taking it upon themselves to generate Return Receipts.  Most people, and
>some standards (like X.400) believe that this is unacceptable.   Whenever
>a return receipt request is detected by a UA, it should first get the approval
>of the user prior to sending out any notification.  As long as the user has
>control of how the UA will deal with return receipt notifications, I don't
>see much of a problem.  If they don't however, for me at least it would 
>represent an unacceptable invasion of privacy, and I would seriously 
>consider the use of another UA for this reason alone.


Among other things needed is a clearer definition or, more exactly, a
model to follow.  Clearly, this is not the model of Certified Mail in
the U.S. Postal System.  Certified Mail gets a return receipt sent to
the sender if the delivery agent delivered the mail.  Also, it gets
signed and stamped in an official, trusted manner.  

1. Certified Mail -- the compliant MTA certifies delivery to the
mailbox.  There may be an option to have this be digitally signed by
the system to have a valid and acceptable time stamp (like a Post
Office rubber date stamp).  This transaction is between the MTA and
the sender and the receiver should not have to okay this.  It is
certifying delivery. ("I did too get the RFP response to you on time.
See?  Here's my certified delivery report with a certifiable digital
signature."  Side note.  Someone who worked for me once scrambled to
get something FAXed to a customer before the 5pm deadline.  Customer
the week later said "We didn't look at it.  It was FAXed to us at
5:45PM -- not before 5pm!"  well...  No one had changed the clocks on
our FAX machines nor had anyone changed the clocks on theirs when
daylight savings time ended.  Easy to verify since they still
hadn't....  Did you change YOUR FAX machines? :-))

2. Read Receipt Requested.  The compliant UA should indicate "A Read
Receipt was requested.  Shall I send one?"  For non-smart UA's, The
header line should indicate to the reader that they are being asked to
confirm their reading it.

F

In article <9212311441.AA06064@TIS.COM> avolio@TIS.COM writes:
| 
| Among other things needed is a clearer definition or, more exactly, a
| model to follow.  Clearly, this is not the model of Certified Mail in
| the U.S. Postal System.  Certified Mail gets a return receipt sent to
| the sender if the delivery agent delivered the mail.  Also, it gets
| signed and stamped in an official, trusted manner.  

I'm not sure that an exact mapping of the way the U.S. Postal system does
things is necessarily a good thing.  As you say, the postal system return
receipt is not what I was describing.  I think that a reasonable analogy
would be the the postal return receipt would correspond to a MTA delivery
report.  A user agent return receipt in the USPS world would be more like
the postman coming into your home or business, watching you open you mail,
and then writing a report back to the sender indicating it had been opened.

| 1. Certified Mail -- the compliant MTA certifies delivery to the
| mailbox.  There may be an option to have this be digitally signed by
| the system to have a valid and acceptable time stamp (like a Post
| Office rubber date stamp).

This is an interesting option - but one that I don't believe would be
necessary for most applications.  Perhaps if we were to come up with a
mechanism that would work with and without digital signitures?

| 2. Read Receipt Requested.  The compliant UA should indicate "A Read
| Receipt was requested.  Shall I send one?"  For non-smart UA's, The
| header line should indicate to the reader that they are being asked to
| confirm their reading it.

It should also be acceptable if the remote UA were to do nothing with
the request.  The key here is that it is a "request".

Best Regards,

Tim Kehres