home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 418 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  2.9 KB
  1. Path: sparky!uunet!noc.near.net!news.bbn.com!drilex!dricejb
  2. From: dricejb@drilex.dri.mgh.com (Craig Jackson)
  3. Newsgroups: comp.mail.headers
  4. Subject: Re: Return-Receipt-To & forwarding...
  5. Date: 3 Jan 93 00:43:40 GMT
  6. Organization: DRI/McGraw-Hill, Lexington, MA
  7. Lines: 51
  8. Message-ID: <51785@drilex.dri.mgh.com>
  9. References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <davecb.725771350@yorku.ca> <1hv93pINNc85@gaia.ucs.orst.edu> <davecb.725910818@yorku.ca>
  10. NNTP-Posting-Host: bbn.com
  11.  
  12. Here are some of my thoughts on this subject:
  13.  
  14. 1. I consider the lack of a good receipt system to be a major limitation
  15. to internet (small i) mail.
  16.  
  17. 2. In snail mail, the intent of receipts is not to report that the mail
  18. has actually been read by the intended human and comprehended.
  19. It is instead an indication that the recipient or the 
  20. recipient's authorized and identified agent has been made
  21. aware of the message, and therefore the intended recipient *should have*
  22. read it (or otherwise dealt with it).
  23.  
  24. In other words, these receipts say "We delivered this message at such-and-such
  25. time, and so-and-so at the proper address signed for it,
  26. so it isn't our fault if the intended recipient hasn't read it" or
  27. "We delivered your mail to the proper address at such-and-such time, but
  28. so-and-so refused it" or possibly "We tried to deliver your mail, but no one
  29. could be found to accept or refuse it".
  30.  
  31. 3. Most proprietary Email systems have a receipt system, with similar semantics
  32. to the snail-mail receipts.  They also generally maintain more control
  33. over the mail before final display than the average UNIX mail implementation,
  34. so the receipts are fairly reliable.
  35.  
  36. 4. The invasion of privacy of receipts is frequently mentioned.  However,
  37. under the definition of (2) above, then the purpose of the receipt request is
  38. to absolve the delivery system of responsibility and to place the onus
  39. on the recipient.
  40.  
  41. By analogy, if an Email UA offers the opportunity for the recipient to
  42. refuse to send the receipt back, it should also refuse to show the mail
  43. to the recipient, and a delivery-refused indication should be returned.
  44.  
  45. 5. Not all internet mail is handled in a single interactive SMTP hop.
  46. Even Internet mail can still go through several hops via the deprecated-
  47. but-not-eliminated mechanism of source routing, and via the tacitly-approved
  48. "%" hack.  Therefore,  presence or absence of certain SMTP indications
  49. does not necessarily indicate delivery to the final mail store, let alone
  50. having been presented to the intended recipient.
  51.  
  52. 6. Two other notes of the snail-mail analog:
  53.  
  54. a. One aspect of a snail-mail receipt is a signature.  A truly accurate
  55. Email model would require a digital signature system.
  56.  
  57. b. Snail-mail receipts are nearly always extra-cost items.  I don't know
  58. of any mechanism for modelling this in the internet environment.
  59. -- 
  60. Craig Jackson -- cjackson@mgh.com (Straight Internet)
  61. dricejb@drilex.dri.mgh.com (uucp-forwarded)
  62. {bbn,alliant,redsox}!drilex!{dricej,dricejb}
  63.