HDTenEightyP/NetNews huggingface dataset:
From: kehres@ima.com (Tim Kehres)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Keywords: delivery receipts
Date: 31 Dec 92 00:56:16 GMT
Followup-To: comp.mail.headers
Organization: International Messaging Associates, Menlo Park, California

In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
| 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.

My past experience with the LLNL EM code with the Air Force and several
other US government organizations does not agree with this.  Our ability
to provide both return receipt and delivery notification functionality
to our clients was a significant reason that they used the software.  It
was heavily used, and found to be quite useful by most of the people using
the software.

| 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.

In most of the cases, a positive response is all that is required.  Keep
in mind if there was a problem with delivery, many times a negative
acknowledgement is sent, although this is not guaranteed.  

Assuming you make the final delivery program responsible for the delivery
report, and this reports makes its way back to the originator of the message,
I don't understand your comment about the system not being foolproof.

| 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.

Sounds like broken software to me, not necessarily an argument against the
functionality.

Best Regards,

Tim Kehres
Newsgroups: comp.mail.headers,comp.mail.misc
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Organization: Bruce Lilly
Date: Sat, 2 Jan 93 04:29:41 GMT
Reply-To: lilb@sony.compuserve.com (Bruce Lilly)

In article <davecb.725911218@yorku.ca>,
 posted to comp.mail.headers,comp.mail.misc,
 davecb@nexus.yorku.ca (David Collier-Brown) wrote:
>
>  This assumes store-and forward, something which is getting
>less and less poplular at time passes, and was never part of
>the RFC world anyway. 

Assuming that for each message sent, one does not
a)	directly open an SMTP connection to the recipient's host
	(assuming such a connection even exists)
and
b)	the SMTP command SEND or SAML (not SOML or MAIL) is used,
	and that on failed delivery the entire message is rekeyed manually
	by the originator
then mail is inherently store-and-forward to some extent.  RFC822 and
RFC1123 both provide mechanisms for routing of mail, which usually is
implemented as store-and-forward. And let's not forget RFC976, which
specifically applies to UUCP mail (inherently store-and-forward).

As the use of computers and computer-based mail grows within an
organization, it is often the case that mail gateways are set up to offload
mail transport handling tasks from individual workstations. Often the mail
gateways will store mail, later forwarding it to a workstation, or to another
machine.  I submit, therefore, that store-and-forward may actually become
more widely used, not less so, within the Internet.

As network topologies and sizes change, it is sometimes enlightening to review
one's assumptions. To take another mail-related example, it used to be the
case that a moderate number of "hops" (say two dozen) could be considered to
be an indication of a mail loop.  Today it is possible to easily reach
several dozen hops (via gateway and firewall machines) even within a small
organization. Result: hop count alone is probably no longer useful as an
indication of a mail loop (if it ever was).

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce
Newsgroups: comp.mail.headers,comp.mail.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Return-Receipt-To & forwarding...
Organization: York University
Date: Fri, 1 Jan 1993 17:53:38 GMT

stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
|you didn't get a "599 ..." response. You don't even know that such a
|response wasn't sent, only that you didn't get one. You certainly don't
|know that the mail you sent was delivered.

Short answer: 
	Go read RFC821/2 (and consider yourself insulted).

Long answer:
	Mail is a reliable, end-to-end service, and must 
	actively acknowlege both receipt and errors.  An
	exception is made for one case (where an error
	indication would be ambiguous), but in that case
	a duty to reurn a mail message with notice of
	the error is imposed.

	Gateways which do not support the above are possible
	(the PC-critters are good at that), but no-one claims
	they're standard-conforming.

--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.
Newsgroups: comp.mail.headers,comp.mail.misc
From: rstory@elegant.com (Robert Story)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Date: Wed, 30 Dec 1992 17:18:44 GMT
Organization: Elegant Communications Inc.
Keywords: delivery receipts

In article <1992Dec30.072811.3737@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:
> In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
> > I apologize for the length, but this is something I feel fairly
> > strongly about.  Sprinkle liberally with IMHOs.
> 
> Here Here!  Thanks John!
> 
> > 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.
> 
> I'll go even further:  they are "dangerous" in the sense that they
> provide incomplete information a false sense of security.  As John
> said later in his article -- "User expectation is perhaps the biggest
> problem."  User's I know who say they like this feature are
> *completely* mislead by it.
> 
> I'll re-iterate too that even if you get a response, then there's no
> guarantee the remote reader will be able to respond, since there's no
> way to track between the MTA which thinks it performed final delivery,
> and the MUA.

Personally, I'm *quite* happy to know that the user's "system" got
it.  It gives a least some degree of assurance (and besides it makes
me feel all warm inside!).

> If you want to get a message through to someone, the only sure way to
> receive confirmation is out-of-band from the original delivery channel.
So, no reply then telephone?  Of course, if you get the person's voice
mail you're in the same pickle ... how about a personal visit
(assuming that the person is not on vacation and still works there!???)

> How about updating the mail standards to say that such features are
> not permitted!  :-)
Tut, tut!  :-/

Doesn't X.400 have a means of verifying receipt?

				    -Robert.
--
 _________________________________________________________________________
 Robert.Story@Elegant.COM                      Elegant Communications Inc.
 Tel: +1 416 362 9772                        4 King Street West Suite 1101
 Fax: +1 416 362 8324                     Toronto, Ontario; CANADA M5H 1B6

Newsgroups: comp.mail.headers,comp.mail.misc
From: hanrahan@iron.hq.aflc.af.mil (Kevin Hanrahan)
Subject: Re: Return-Receipt-To & forwarding...
Organization: U.S. Air Force Security Assistance Center (AFSAC)
Date: Sun, 27 Dec 1992 19:50:38 GMT


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            

Xref: sparky comp.mail.headers:409 comp.mail.misc:4199
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Date: 2 Jan 1993 04:40:05 GMT
Organization: Oregon State University, College of Oceanography
NNTP-Posting-Host: skyking.oce.orst.edu

In article <davecb.725911218@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  This assumes store-and forward, something which is getting
>less and less poplular at time passes, and was never part of
>the RFC world anyway. 

Funny, Dave. Seems that store-and-forward is still a part of the "RFC
world". I guess you have never seen sendmail fail to deliver a message
and keep it in the mail queue until {it could|three days}. 

You're so lucky, never sending mail to a system that is down. Tell us
all how you do it? Do you ping every recipient's host to make sure it is
up before you send the mail? That doesn't guarantee that there is a
working mail demon -- you must do a manual SMTP connection and just not
count the times that you can't connect in your definition of
"reliable".

Or have you just never noticed it happening so it doesn't exist for
you?

Newsgroups: comp.mail.headers,comp.mail.misc,comp.mail.sendmail
From: bruce@blilly.UUCP (Bruce Lilly)
Subject: Re: Return-Receipt-To & forwarding...
Followup-To: comp.mail.sendmail
Organization: Bruce Lilly
Date: Fri, 25 Dec 92 16:19:48 GMT
Reply-To: lilb@sony.compuserve.com (bruce Lilly)

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
Newsgroups: comp.mail.headers,comp.mail.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Organization: York University
Date: Fri, 1 Jan 1993 18:00:18 GMT

bruce@blilly.UUCP (Bruce Lilly) writes:
|Lack of a bounce message tells me nothing useful:
|	the message might have been delivered successfully to the
|		intended destination
|	the message might have been misdirected, and possibly
|		delivered somewhere other than the intended
|		destination
|	the message may have fallen into a bottomless pit at a
|		store-and-forward site
|	delivery may have failed somewhere with a bounce message,
|		but the bounce message may have been misdirected
|		or lost or both
|	several possible combinations of the above
|	the message may be waiting at a store-and-forward site

  This assumes store-and forward, something which is getting
less and less poplular at time passes, and was never part of
the RFC world anyway. Indeed, even my local uucp net is 
quickly turning into an ip/slip net...
  If a store-and-forward system like uucp is used, the reliability
is surprizingly high (a few messages a year go missing when someone
blows a disk).  It's some other *@$#%!*!^#5 systems that poste the problems
and make return receipts necessary.

  Please note that most commercial PC mailrs provide themm.  There's
a reason for that (:-()

--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.
Newsgroups: comp.mail.headers,comp.mail.misc
From: woods@robohack.UUCP (Greg A. Woods)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Organization: Elegant Communications Inc.
Keywords: delivery receipts
Date: Wed, 30 Dec 92 07:28:11 GMT

In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
> I apologize for the length, but this is something I feel fairly
> strongly about.  Sprinkle liberally with IMHOs.

Here Here!  Thanks John!

> 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.

I'll go even further:  they are "dangerous" in the sense that they
provide incomplete information a false sense of security.  As John
said later in his article -- "User expectation is perhaps the biggest
problem."  User's I know who say they like this feature are
*completely* mislead by it.

I'll re-iterate too that even if you get a response, then there's no
guarantee the remote reader will be able to respond, since there's no
way to track between the MTA which thinks it performed final delivery,
and the MUA.

Yes, a "Read-receipt-to:", implemented in the MUA, might be OK, but
does assume some degree of user intervention, but then with the
proliferation of things like vacation, this point is rather
out-weighed.  I think the user demand has been driven by several
things:  1) the historical lack of reliable e-mail; 2) the never
ending drive to keep track of one's fellow man; 3) historical
frustration with non-electronic mail.

If you want to get a message through to someone, the only sure way to
receive confirmation is out-of-band from the original delivery channel.

Then there's the mailing list problem.....

How about updating the mail standards to say that such features are
not permitted!  :-)
-- 
						Greg A. Woods

woods@robohack.UUCP, woods@Elegant.COM  VE3TCP	UniForum Canada & ECI
+1 416 443-1734 [home] +1 416 362-XRSA [work]	Toronto, Ontario; CANADA
Xref: sparky comp.mail.headers:416 comp.mail.misc:4215
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
From: Andy.Linton@comp.vuw.ac.nz (Andy Linton)
Date: Sat, 2 Jan 1993 23:58:00 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <davecb.725999782@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:

>Ah, good, some actual facts to discuss.
>
>Yes, I've noticed that I've had to increase the threshold for
>loop-detection because of sites as far away as New Zealand and Georgia
>(in the former USR, not the U.S.), and tht does indicate more
>store-and-forward connections on the periphery of the Internet, thus
>supporting your position.

I'm a little surprised to find New Zealand mentioned here as being on
the periphery of the Internet connected via store and forward
connections. I would have though that a round trip ping time of 800 ms
to mailhub.yorku.ca given that one of the hops in the link is a
trans-Pacific satellite connection makes us as well connected as many
other non US or CA sites. That satellite link goes straight into FIX
West by the way.

If you need to increase the threshold to get mail to us then
somethings broken.

Newsgroups: comp.mail.headers,comp.mail.misc
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: Return-Receipt-To & forwarding...
Organization: York University
Date: Sat, 2 Jan 1993 22:47:28 GMT

barr@pop.psu.edu (David Barr) writes:
|Sorry, I have to agree with John Stanley on this one.  In addition
|to the scenario John mentioned, consider the following:
[scenario which make outdoing mail fail from a site]

With respect, any system, reliable or not, can be buggered up.  That doesn't
make the system unreliable (ie, it does not change its underlying character).

   Mr. Stanley is raving mad (in the sense of angry, not insane, but
also consider fingering him and making up your own mind) and is
arguing events which may well have taken place somewhere, some time.
They are seriously unusual and do not justify the establishment of the
return receipt mechanism.

  York is the second-largest and second-cheapest university in Canada,
and one of our three main mailhubs processes between 100 and 200
thousand messages per month (see below). 

Jun 1991 4729 x
Jul 1991 4423 x
Aug 1991 43405 xxxxx
Sep 1991 84828 xxxxxxxxx
Oct 1991 62510 xxxxxxx
Nov 1991 164421 xxxxxxxxxxxxxxxxx
Dec 1991 202805 xxxxxxxxxxxxxxxxxxxxx
Jan 1992 93286 xxxxxxxxxx
Feb 1992 116862 xxxxxxxxxxxx
Mar 1992 132674 xxxxxxxxxxxxxx
Apr 1992 137614 xxxxxxxxxxxxxx
May 1992 144873 xxxxxxxxxxxxxxx
Jun 1992 112393 xxxxxxxxxxxx
Jul 1992 186773 xxxxxxxxxxxxxxxxxxx
Aug 1992 115636 xxxxxxxxxxxx
Sep 1992 122207 xxxxxxxxxxxxx
Oct 1992 202904 xxxxxxxxxxxxxxxxxxxxx
Nov 1992 193313 xxxxxxxxxxxxxxxxxxxx
Dec 1992 191306 xxxxxxxxxxxxxxxxxxxx

 It is a rare event and a major concern when messages go missing or
unanswered in a given month: my job depends on the reliable operation
of SMTP.
  If memory serves, we had about three panics (searches for missing
messages) last year, out of 1.8m+.  That still makes my blood run cold...

--dave 
ps: we use Rayan's Zmailer from UofT and pop/imap: the comment
  below about sendmail is becoming less and less true. (Special thanks
  to ozan for leading me to the true religion: zmailer is programmable
  by mere mortals)
-- 
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.
Newsgroups: comp.mail.headers,comp.mail.misc
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: Return-Receipt-To & forwarding...
Date: 1 Jan 1993 19:06:55 GMT
Organization: Oregon State University, College of Oceanography
NNTP-Posting-Host: skyking.oce.orst.edu

In article <davecb.725910818@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>|you didn't get a "599 ..." response. You don't even know that such a
>|response wasn't sent, only that you didn't get one. You certainly don't
>|know that the mail you sent was delivered.
>
>Short answer: 
>	Go read RFC821/2 (and consider yourself insulted).

You had better expand on that answer, for neither RFC appears to claim
anything opposite to what I wrote. And, since both RFC's deal only with
Internet standards, and since electronic mail can cross network
boundaries to systems which have no requirement to use SMTP (much less
obey Internet RFC's), neither can speak definitively on what I wrote.

>Long answer:
>	Mail is a reliable, end-to-end service, and must 

Thanks for the laugh. You may think that mail is reliable, but that
don't make it so. RFC 822 makes no mention of "reliable", and RFC 821
mentions it in two instances, one of which specifies the use of a
"reliable transport" mechanism. 

The other says that the objective of the SMTP standard is reliability.
If you believe that this statement of objective is identical to a
description of the current implementations, then consider yourself
insulted.

>	actively acknowlege both receipt and errors.  

Even were this statement true, it does not prove that mail will always
arrive at the intended recipient nor that error replies will arrive at
the originator. 

>	Gateways which do not support the above are possible
>	(the PC-critters are good at that), 

So are the UNIX critters, and the IBM critters, and every other
critter. I know of no system, PC or otherwise, which actively acks
receipt, unless the originator has requested it. That doesn't mean they
don't exist, just that they aren't real common.

>       but no-one claims they're standard-conforming.

This, of course, begs the question, whose standard? 

Xref: sparky comp.mail.headers:419 comp.mail.misc:4217