home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 385 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.3 KB
  1. Xref: sparky comp.mail.headers:385 comp.mail.misc:4147
  2. Newsgroups: comp.mail.headers,comp.mail.misc
  3. Path: sparky!uunet!utcsri!geac!torag!robohack!woods
  4. From: woods@robohack.UUCP (Greg A. Woods)
  5. Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
  6. Organization: Elegant Communications Inc.
  7. References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <1992Dec28.171751.25819@chance.gts.org>
  8. Message-ID: <1992Dec30.072811.3737@robohack.UUCP>
  9. Keywords: delivery receipts
  10. Date: Wed, 30 Dec 92 07:28:11 GMT
  11. Lines: 41
  12.  
  13. In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
  14. > I apologize for the length, but this is something I feel fairly
  15. > strongly about.  Sprinkle liberally with IMHOs.
  16.  
  17. Here Here!  Thanks John!
  18.  
  19. > My position on this is that receipts are only genuinely useful if they
  20. > are guaranteed.  Since we can't get this with the loose email net we
  21. > have, it's not useful.
  22.  
  23. I'll go even further:  they are "dangerous" in the sense that they
  24. provide incomplete information a false sense of security.  As John
  25. said later in his article -- "User expectation is perhaps the biggest
  26. problem."  User's I know who say they like this feature are
  27. *completely* mislead by it.
  28.  
  29. I'll re-iterate too that even if you get a response, then there's no
  30. guarantee the remote reader will be able to respond, since there's no
  31. way to track between the MTA which thinks it performed final delivery,
  32. and the MUA.
  33.  
  34. Yes, a "Read-receipt-to:", implemented in the MUA, might be OK, but
  35. does assume some degree of user intervention, but then with the
  36. proliferation of things like vacation, this point is rather
  37. out-weighed.  I think the user demand has been driven by several
  38. things:  1) the historical lack of reliable e-mail; 2) the never
  39. ending drive to keep track of one's fellow man; 3) historical
  40. frustration with non-electronic mail.
  41.  
  42. If you want to get a message through to someone, the only sure way to
  43. receive confirmation is out-of-band from the original delivery channel.
  44.  
  45. Then there's the mailing list problem.....
  46.  
  47. How about updating the mail standards to say that such features are
  48. not permitted!  :-)
  49. -- 
  50.                         Greg A. Woods
  51.  
  52. woods@robohack.UUCP, woods@Elegant.COM  VE3TCP    UniForum Canada & ECI
  53. +1 416 443-1734 [home] +1 416 362-XRSA [work]    Toronto, Ontario; CANADA
  54.