home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / headers / 381 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.3 KB
  1. Xref: sparky comp.mail.headers:381 comp.mail.misc:4130
  2. Newsgroups: comp.mail.headers,comp.mail.misc
  3. Path: sparky!uunet!noc.near.net!lynx!tmetro
  4. From: tmetro@lynx.dac.northeastern.edu (Thomas Metro)
  5. Subject: Re: Return-Receipt-To & Mailing lists
  6. Message-ID: <1992Dec29.075730.21796@lynx.dac.northeastern.edu>
  7. Organization: Venture Logic, Newton, MA
  8. References: <19921225.001@erik.naggum.no> <sdorner-271292095054@0.0.0.0> <Bzzt68.G8z@boulder.parcplace.com>
  9. Date: Tue, 29 Dec 1992 07:57:30 GMT
  10. Lines: 40
  11.  
  12. Warner Losh writes:
  13. > The biggest question about Return-Receipt-To: is what to do when a
  14. > nieve user sends mail to a mailing list with this header in it.
  15. This opens another can of worms.
  16. There is a lot of automated software that can be broken by mailing lists.
  17. What would be nice is an RFC for mailing lists.
  18. Something that could describe the behavior of the list management
  19. software (such as how it deals with "Return-Receipt-To:"), header
  20. definitions (such as "Listname:" to identify the list(s) ), and some
  21. facilities to ease the integration of mailing lists into news systems.
  22.  
  23. > It would be critical that mailing lists and such filter out 
  24. > Return-Receipt-To:.  
  25. The list management software should acknowledge the receipt of the message
  26. by sending an appropriate notice, and then remove the
  27. "Return-Receipt-To:" header before forwarding the message.
  28.  
  29. > Return-Receipt-To is a dangerous header as it stands now.  If its use
  30. > is to be standardized, its meaning much change :-)
  31. The temptation is there to try and use what already exists to some extent,
  32. but there appears to be a lot of interest in something with more
  33. functionality.
  34.  
  35. Perhaps the existing functionality of sendmail's "Return-Receipt-To:"
  36. should be captured in an RFC, but then the idea should be extended to also
  37. include a "Read-Receipt-To:" header (or equivalent) for the MUA. This new
  38. header could then include added features (such as dealing with multiple
  39. recipients).
  40.  
  41. As to the issue of whether "Return-Receipt-To:" has any value: yes, it
  42. will be less meaningful until it is standardized and becomes ubiquitous.
  43. But isn't that always the case with protocols?
  44.  
  45. What should happen when crossing a gateway, and there is no equivalent to
  46. a "Return-Receipt-To:" or "Read-Receipt-To:" on the other side? Should the
  47. gateway send an appropriate message?
  48.  
  49.  -Tom
  50.  
  51. tmetro@lynx.dac.northeastern.edu
  52.