home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 376 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.7 KB
  1. Xref: sparky comp.mail.headers:376 comp.mail.misc:4103
  2. Newsgroups: comp.mail.headers,comp.mail.misc
  3. Path: sparky!uunet!cis.ohio-state.edu!udecc.engr.udayton.edu!blackbird.afit.af.mil!iron!hanrahan
  4. From: hanrahan@iron.hq.aflc.af.mil (Kevin Hanrahan)
  5. Subject: Re: Return-Receipt-To & forwarding...
  6. Message-ID: <BzxoGE.FIB@iron.hq.aflc.af.mil>
  7. Organization: U.S. Air Force Security Assistance Center (AFSAC)
  8. References: <1992Dec20.022054@avsht.sph.spb.su> <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0>
  9. Date: Sun, 27 Dec 1992 19:50:38 GMT
  10. Lines: 45
  11.  
  12.  
  13. sdorner@qualcomm.com (Steve Dorner) writes:
  14.  
  15. >I think it is high time that some form of standard return receipt were
  16. >available in Internet mail.  It's one of the few functional areas where the
  17. >Internet lags behind practically ever proprietary mail system, and X.400 to
  18. >boot.
  19.  
  20. >My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
  21. >successful delivery, since it has some utility and is also not going to go
  22. >away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
  23. >would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
  24. >ONLY the MUA) when the message is actually read.
  25. >--
  26. >Steve Dorner, Qualcomm, Inc.
  27.  
  28.    I would tend to agree with your leaning, but several SMTP compatible
  29. mail packages already implement "Return-Receipt-To:" as a read
  30. receipt (Control Data's ASCENT*Mail is one of these and is widely
  31. used in the U.S. Air Force).  I had the pleasure of hacking "elm"
  32. to recognize and implement this header for an Air Force customer
  33. who demanded this capability and desired compatibility with
  34. existing systems.
  35.  
  36.   My recommendation on this subject however, would not be to
  37. try to formalize the "Return-Receipt-To:" header (or create
  38. a Read-Receipt-Header), but instead to attempt to take advantages
  39. of MIME, which is now gaining rapid popularity.  By using MIME's
  40. content type/subtype classifications similar to "message/external-body",
  41. one could implement read receipts at the MUA level as you suggested,
  42. but probably with much greater ease.  A good example of how
  43. this could be done is the MIME compliant messages sent out by
  44. the IETF announcing new/proposed RFC's.  When these messages are
  45. read with a MIME compliant reader, the user is given the opportunity
  46. to automatically send a request to a mail server.
  47.  
  48.   Although metamail's "showexternal" script is not ideally suited
  49. to read receipts, perhaps a new MIME subcontent type definition
  50. (and accompanying metamail script for MIME readers using metamail) i
  51. would allow the easiest and most elegant implementation of read receipts.
  52.  
  53. --
  54. Kevin M. Hanrahan            hanrahan@wpsp01.hq.aflc.af.mil
  55. C.E.T.A. Corporation
  56. Beavercreek, OH              (513) 427-CETA            
  57.  
  58.