home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2271 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  3.5 KB
  1. Path: sparky!uunet!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. Newsgroups: vmsnet.mail.pmdf
  3. Subject: RE: Limiting access to outgoing mail.
  4. Message-ID: <01GOMWWKNOPU9FMFX6@INNOSOFT.COM>
  5. From: "Daniel C. Newman" <dan@innosoft.com>
  6. Date: 10 Sep 1992 22:49:01 -0700 (PDT)
  7. Organization: The Internet
  8. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  9. Resent-Date: 10 Sep 1992 22:49:01 -0700 (PDT)
  10. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  11. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  12. Resent-Message-ID: <01GOMWXKVUGY984MEX@YMIR.CLAREMONT.EDU>
  13. X-Vms-To: IN%"kraftjoel@bvc.edu"
  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: 58
  19.  
  20. > We have the exact same situation here on our campus, and I think that the
  21. > solution is just a bit impractical.  On our campus, there are over 1000
  22. > accounts that *should* be able to use mail, but only about 50 that should
  23. > not.  Our system would be a rightslist nightmare if we tried this.
  24.  
  25. We at Innosoft certainly agree that the present mechanisms in PMDF are not
  26. terribly practical.  We've already implemented in PMDF V4.2 a new, more
  27. practical mechanism.  We're also planning some new ACL based mechanisms since
  28. VMS is moving more-and-more in that direction with new and improved ACL support
  29. anticipated.
  30.  
  31. The input from the PMDF community has, as always, been quite helpful and was
  32. what gave us the final nudge a few months back to implement the new support in
  33. V4.2.
  34.  
  35. I shall summarize below the new support so that anyone spotting any missing
  36. functionality, blunders, or whatnot can bring them to our attention now,
  37. well in time for the next release.  And of course, further ideas are always
  38. welcome.
  39.  
  40. The new support is implemented with a table in the mapping file.  Entries
  41. in this table specify: the channel a message is coming from, the address of
  42. the sender, the channel a message is going to, the to address, and finally
  43. whether or not to permit the message to pass to the "to" channel:
  44.  
  45.     from_channel|from_address|to_channel|to_address     $Y/$N
  46.  
  47. Wild cards may be used for any or all of the first four items in an entry.
  48. If a message is not permitted to pass to the to channel, then it is bounced
  49. back to the from address.  Optionally, an error message to be returned with
  50. the bounced message may be specified.
  51.  
  52. The ability to specify wild cards makes this facility quite flexible.  Clearly,
  53. however, when there is no pattern to a set of to or from addresses requiring
  54. access control, this scheme devolves to creating individual entries for each
  55. address in that set.  It is here that ACL schemes or some other mechanism may
  56. prove more apt.
  57.  
  58. Dan
  59.  
  60. ----------------------------------------------------------------------------
  61. >>         I'd like to be able to limit access to non-local (off-node) email.
  62. >> I'm thinking that I can define a rights id, say 'NO_OUTMAIL' for example,
  63. >> and set the appropriate image with an ACL such that anyone holding that id
  64. >> cannot send internet mail messages.  My questions are simple:  Will this
  65. >> work?  and, which image(s) should be set this way?
  66. >
  67. > This won't work since the users only run VMS MAIL or DECWindows MAIL.  They
  68. > don't run the actual images which send outbound mail.  Instead, you probably
  69. > want to associated this rightlist identifier with, say, your TCP/IP channel.
  70. > You do this by merely specifying the rightlist id as a channel keyword; e.g.,
  71. >
  72. >         mtcp_local single smtp mx no_outmail
  73. >
  74. > Then, only processes with the no_outmail rightslist id can queue mail to
  75. > the mtcp_local channel.  Be sure to grant this rightslist id to whatever
  76. > accounts PMDF may run under!
  77.  
  78.