home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 393 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.5 KB
  1. Xref: sparky comp.mail.headers:393 comp.mail.misc:4169
  2. Path: sparky!uunet!wupost!usc!elroy.jpl.nasa.gov!decwrl!sooner.palo-alto.ca.us!ima!kehres
  3. From: kehres@ima.com (Tim Kehres)
  4. Newsgroups: comp.mail.headers,comp.mail.misc
  5. Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
  6. Keywords: delivery receipts
  7. Message-ID: <293@ima.com>
  8. Date: 31 Dec 92 00:56:16 GMT
  9. References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <1992Dec28.171751.25819@chance.gts.org>
  10. Followup-To: comp.mail.headers
  11. Organization: International Messaging Associates, Menlo Park, California
  12. Lines: 40
  13.  
  14. In article <1992Dec28.171751.25819@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
  15. | My position on this is that receipts are only genuinely useful if they
  16. | are guaranteed.  Since we can't get this with the loose email net we
  17. | have, it's not useful.
  18.  
  19. My past experience with the LLNL EM code with the Air Force and several
  20. other US government organizations does not agree with this.  Our ability
  21. to provide both return receipt and delivery notification functionality
  22. to our clients was a significant reason that they used the software.  It
  23. was heavily used, and found to be quite useful by most of the people using
  24. the software.
  25.  
  26. | With return-receipt-to, a lack of response means nothing (your message
  27. | may or may not have been delivered), and a positive response means
  28. | there's a good chance your message was delivered, but it's my no means
  29. | foolproof.
  30.  
  31. In most of the cases, a positive response is all that is required.  Keep
  32. in mind if there was a problem with delivery, many times a negative
  33. acknowledgement is sent, although this is not guaranteed.  
  34.  
  35. Assuming you make the final delivery program responsible for the delivery
  36. report, and this reports makes its way back to the originator of the message,
  37. I don't understand your comment about the system not being foolproof.
  38.  
  39. | User expectation is perhaps the biggest problem.  As a side story, I
  40. | used to work at a place where the admin staff used a "friendly" mailer
  41. | that had read receipts.  One user got very confused because she would
  42. | get replies to her mail, and a day or so later get told by the
  43. | friendly mailer that the recipient had not yet read the mail, even
  44. | though she'd seen the reply.  When the cause was explained, she
  45. | couldn't see the point of the read receipt feature because she was
  46. | expecting something more meaningful.
  47.  
  48. Sounds like broken software to me, not necessarily an argument against the
  49. functionality.
  50.  
  51. Best Regards,
  52.  
  53. Tim Kehres
  54.