home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / sendmail / 3090 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  1.5 KB
  1. Path: sparky!uunet!wupost!usc!elroy.jpl.nasa.gov!decwrl!sooner.palo-alto.ca.us!ima!kehres
  2. From: kehres@ima.com (Tim Kehres)
  3. Newsgroups: comp.mail.sendmail
  4. Subject: Re: Return-Receipt-To & forwarding...
  5. Message-ID: <292@ima.com>
  6. Date: 31 Dec 92 00:45:06 GMT
  7. References: <1992Dec20.022054@avsht.sph.spb.su> <1992Dec25.161948.9506@blilly.UUCP>
  8. Organization: International Messaging Associates, Menlo Park, California
  9. Lines: 23
  10.  
  11. In article <1992Dec25.161948.9506@blilly.UUCP> lilb@sony.compuserve.com (bruce Lilly) writes:
  12. :
  13. > >Should my mailer send one more notifying message to the
  14. > >author?
  15. > 
  16. > I believe that it should not do so (I was once bombarded by return receipts
  17. > after sending a bug report to one of FSF's bug-reporting addresses, which
  18. > expanded to a mailing list).
  19.  
  20. This is one reason why return receipt and delivery notification requests
  21. should be standarized.  If standardized, then the distribution list software
  22. could be modified to look for these requests, and perform the required 
  23. function.  For most lists, I would suspect that no action would be taken
  24. for a return receipt request, other than its removal from the header.  A 
  25. delivery notification request however would generate a reply back to the 
  26. originator indicating final delivery to the list, and then remove the request
  27. from the header.  There are some list maintainers however that may wish to 
  28. pass these requests through the list, and that should be allowed, if that is 
  29. what the owner of the list desires.
  30.  
  31. Best Regards,
  32.  
  33. Tim Kehres
  34.