home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 391 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  5.1 KB
  1. Xref: sparky comp.mail.headers:391 comp.mail.misc:4167
  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-Receipt-To & forwarding...
  6. Message-ID: <290@ima.com>
  7. Date: 31 Dec 92 00:24:22 GMT
  8. References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <BzxoGE.FIB@iron.hq.aflc.af.mil>
  9. Followup-To: comp.mail.headers
  10. Organization: International Messaging Associates, Menlo Park, California
  11. Lines: 84
  12.  
  13. In article <BzxoGE.FIB@iron.hq.aflc.af.mil> hanrahan@iron.hq.aflc.af.mil (Kevin Hanrahan) writes:
  14. > 
  15. > sdorner@qualcomm.com (Steve Dorner) writes:
  16. > 
  17. > >I think it is high time that some form of standard return receipt were
  18. > >available in Internet mail.  It's one of the few functional areas where the
  19. > >Internet lags behind practically ever proprietary mail system, and X.400 to
  20. > >boot.
  21.  
  22. I could not agree more.  Over the past few years, I have attempted within
  23. the IETF to generate some interest in this, and have been unable to make
  24. any progress.  My position is that there really needs to be two separate
  25. mechanisms in place - one for UA return receipts, and a delivery 
  26. acknowledgement mechanism that the final delivery agent can use to notify
  27. the originator that the message has been delivered.  In addition, the 
  28. mechanisms need to operate across gateways, hence cannot be tied to any
  29. particular transport mechanism.
  30.  
  31. > >My initial leaning is to enshrine "Return-Receipt-To:" as a standard for
  32. > >successful delivery, since it has some utility and is also not going to go
  33. > >away anytime soon (rampant fantasies of sendmail haters aside :-)).  But I
  34. > >would also suggest a "Read-Receipt-To:", to be generated by the MUA (and
  35. > >ONLY the MUA) when the message is actually read.
  36. > >--
  37. > >Steve Dorner, Qualcomm, Inc.
  38. > 
  39. >    I would tend to agree with your leaning, but several SMTP compatible
  40. > mail packages already implement "Return-Receipt-To:" as a read
  41. > receipt (Control Data's ASCENT*Mail is one of these and is widely
  42. > used in the U.S. Air Force).  I had the pleasure of hacking "elm"
  43. > to recognize and implement this header for an Air Force customer
  44. > who demanded this capability and desired compatibility with
  45. > existing systems.
  46.  
  47. I would have to disagree with the use of Return-Receipt-To.  As the person
  48. that wrote the code for the return receipt functionality in the LLNL EM
  49. code (which ASCENT*Mail is derived from), I am somewhat familiar with what
  50. went into the decision to use Return-Receipt-To.  :-)  We had a strong desire 
  51. on the part of the Air Force to be able to determine when a message arrived
  52. at it's destination.  Upon further discussions with the client, we found
  53. that what was really desired was an ability for the sender to know when
  54. the message was sucessfully delivered to the recipient - in other words
  55. a devliery report, *not* a return receipt.  Unfortunately, we were unable
  56. to generate our own header fields, so we had the option of using X- fields
  57. for new functionality or overloading Return-Receipt-To.  We chose to do the
  58. latter, and provide both functions as the result of a single request.
  59.  
  60. To make this work properly, two things were also done - we first supplied
  61. our own version of sendmail, with the return receipt code torn out.  In 
  62. addition, we had our own local mail delivery program, which was responsible
  63. for the generation of delivery notifications reports.   The later was a major
  64. win, since very few people seem to be able to tell the difference between
  65. a sendmail delivery report (what it improperly calls a return receipt), and
  66. an error message.  The new delivery agent, which really is the only agent
  67. capable of determining the status of final delivery anyway, produced a 
  68. clean, and simple delivery report.
  69.  
  70. In looking back on what was done, it probably would have been better to 
  71. just define two new X- fields for return receipt and delivery acknowledgement
  72. use.  Sendmail is badly broken when it comes to this stuff,  and it is
  73. impractical to think that we will be able to get good fixes out to many of
  74. the existing locations.  For that reason, if Return-Receipt-To was chosen
  75. as the basis for either function, it would only add more confusion to end
  76. users.
  77.  
  78. >   My recommendation on this subject however, would not be to
  79. > try to formalize the "Return-Receipt-To:" header (or create
  80. > a Read-Receipt-Header), but instead to attempt to take advantages
  81. > of MIME, which is now gaining rapid popularity.
  82.  
  83. Either way, a new header type needs to be defined.  I don't really see
  84. any good reason why return receipt/delivery notification functionality
  85. needs to be tied to MIME.  How am I going to tell users that they can
  86. only request one of these functions if the other side is running MIME
  87. compliant UAs and delivery agents?  What do we really gain here?  We 
  88. certainly lose the ability to use these services in environments and/or
  89. messages that are 822 compliant but not MIME compliant, which still make
  90. up the majority of messages in the Internet.  If we are to impliment 
  91. smarter delivery agents, it also unnecessarily complicates that code if
  92. they have to deal with anything more than the 822 header.
  93.  
  94. Best Regards,
  95.  
  96. Tim Kehres
  97.