home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2310 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.5 KB
  1. Path: sparky!uunet!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. Newsgroups: vmsnet.mail.pmdf
  3. Subject: RE: The "Sender:" header and [exe]return.exe
  4. Message-ID: <01GOTEM5XTOS9ZLLFV@SIGURD.INNOSOFT.COM>
  5. From: Ned Freed <ned@sigurd.innosoft.com>
  6. Date: 15 Sep 1992 14:20:46 -0700 (PDT)
  7. Organization: The Internet
  8. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  9. Resent-Date: 15 Sep 1992 14:20:46 -0700 (PDT)
  10. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  11. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  12. Resent-Message-ID: <01GOTEMNX6K29852CQ@YMIR.CLAREMONT.EDU>
  13. X-Vms-To: IN%"gilles@cismhp.univ-lyon1.fr"
  14. X-Vms-Cc: IPMDF
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18. Lines: 43
  19.  
  20. > My configuration: PMDF 4.1-7 & VMS 5.5-1
  21. > [exe]return.com does not send the warning message to the "Sender:"
  22. > header address when this address is not embedded between "<",">"
  23. > characters. Some discussion lists sends mails with such a header, for
  24. > instance:
  25.  
  26. > Sender: owner-info-nets@think.com
  27.  
  28. First, there is no sensitivity in PMDF to <> on addresses. PMDF simply does not
  29. care if the angle brackets are present or not.
  30.  
  31. Second, returning mail to the Sender: address is totally incorrect. It is a
  32. blatant violation of standards (see RFC1123 for details) and can cause major
  33. operational problems, including message loops.
  34.  
  35. > when
  36. > Sender: "The info-nets discussion list" < owner-info-nets@think.com >
  37. > would work. It's a bit annoying because the warning message is sent to
  38. > the original author.
  39.  
  40. The way this is controlled is either by setting the envelope From: address
  41. (which appears as the Return-path:) or the nonstandard Errors-to: address. PMDF
  42. will honor Errors-To: if it is present; this is an extension to the standards
  43. which say the Return-path: should always be used for returning messages.
  44.  
  45. Lists which don't set a proper Return-Path: can expect to have messages
  46. returned to whatever address is in the original Return-path: (usually the
  47. message originator).
  48.  
  49. There is no option in PMDF to use the Sender: header for returns, and in view
  50. of the fact that this would amount to a massive violation of standards there
  51. never will be such an option.
  52.  
  53. > Another question: in PMDF 4.0, I could exclude a channel of the
  54. > "return" mechanism by setting the exclude_list symbol in [exe]return.com.
  55. > How can I achieve such a restriction in PMDF 4.1 ?
  56. > Thank in advance for any help.
  57.  
  58. Set the notices timeout value to a huge value and return will never process
  59. messages on that particular channel. The exclude_list mechanism was never
  60. documented or supported.
  61.  
  62.                 Ned
  63.