home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2257 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.3 KB
  1. Path: sparky!uunet!olivea!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. From: ned@innosoft.com (Ned Freed)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE: Use of mail/prot=deliver_mailshr
  5. Message-ID: <01GOAK1S6BSY9FM7LA@INNOSOFT.COM>
  6. Date: 2 Sep 92 09:31:12 GMT
  7. Organization: The Internet
  8. Lines: 81
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 02 Sep 1992 02:31:12 -0700 (PDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GOAK2IEFR695P2MJ@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IN%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
  15. X-Vms-Cc: IPMDF
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  18. Content-Transfer-Encoding: 7BIT
  19.  
  20. > A long time ago I wrote a procedure to send mail using PMDF
  21. > It uses the format:
  22.  
  23. > $ define/job pmdf_from "soandso"
  24. > $ mail/prot=deliver_mailshr/subj="test" t. "in%""dmpm@dukemc"""
  25.  
  26. > I am not sure why this is so.
  27.  
  28. I have no idea why you would have done this.
  29.  
  30. > One thing I do notice is that rewrite rules behave differently.
  31. > It appears that mail sent with above is not treated as from the
  32. > local channel.  If not, what is its channel?
  33. > Reason I say this is I have some rules that have
  34.  
  35. > $Nl
  36.  
  37. > on them so that they are not used when from the local channel.
  38. > If I send the mail as above these rules are used.
  39. > If I do not use the /prot bit, the rules are not used.
  40.  
  41. If you use /PROTOCOL you're using MAIL_SERVER.EXE and not MAIL.EXE. The
  42. originating channel for all mail from MAIL_SERVER.EXE is the D channel
  43. (assuming you have one). Technically you are in fact sending network mail when
  44. you use the protocol hook so this interpretation is entirely correct.
  45.  
  46. You probably should be rewriting addresses for the D channel in the same way as
  47. you do for the local channel anyway.
  48.  
  49. > One reason for using the above, is that the sender field is what
  50. > I define PMDF_FROM to be.  If I simply send it with
  51.  
  52. > mail/subj="test" t. "in%""dmpm@dukemc"""
  53.  
  54. > The sender field is the username it was sent with and not the logical
  55. > PMDF_FROM -- this causes problems with what I am doing.
  56.  
  57. The Sender: field is defined to be the authentication information that
  58. describes who _really_ sent the message. It would be a major violation of the
  59. intent of the various mail standards to set it to anything but the name of the
  60. user or agent responsible for the actually sending the message. That's what
  61. it is there for.
  62.  
  63. > P.s.  I have tried using PMDF SEND and have same problem with sender field.
  64.  
  65. Sure, and for exactly the same reason.
  66.  
  67. > P.s.s.  What I am trying to do is send mail on behalf of someone and set
  68. >         the return address to go to them.  If someone has a better way I
  69. >         would love to hear it.  Thanks.
  70.  
  71. If you're seeing mail returned (as in delivery failure notices) to the Sender:
  72. address you are dealing with some seriously broken mailers. This is a HUGE
  73. violation of both the relevant mail standards and of host requirements. See
  74. section 5.3.3 of RFC1123 for details.
  75.  
  76. If you are seeing ordinary replies go to the Sender: address this is also an
  77. indication of a broken mailer, although it is not technically violating
  78. anything and probably is not capable of causing nearly as much trouble. Firing
  79. off replies to the Sender: is sometimes useful but it is in no way a sensible
  80. default to take.
  81.  
  82. What all this boils down to is the need to be able to do two things in PMDF.
  83. The first is the ability to set the envelope From: address. The only way to do
  84. this in PMDF currently is by using a mailing list and specifying the return
  85. address associated with the list. Or you can write code... In any case, despite
  86. the fact that this is potentially a very dangerous feature, I have decided to
  87. enhance PMDF SEND to make it possible to do  this. This enhancement will not
  88. appear until the next release of PMDF, however.
  89.  
  90. Second is the ability to set the Sender: address. This effectively amounts to
  91. a sanctioned way to forge mail. And while there are some cases where this is
  92. useful, you have not described any of them here. Acting on behalf of another
  93. user does not necessarily give you the right to pretend that the other
  94. user did in fact send a particular message.
  95.  
  96. Accordingly, while we do plan to add the ability to do this to PMDF SEND (also
  97. in the next release), it is going to require privileges. And the need to have
  98. privileges to do it is unlikely to be relaxed in the future.
  99.  
  100.                 Ned
  101.