Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"kraftjoel@bvc.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 11 Sep 92 08:46:44 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Limiting access to outgoing mail.
Newsgroups: bit.listserv.pmdf-l

> We have the exact same situation here on our campus, and I think that the
> solution is just a bit impractical.  On our campus, there are over 1000
> accounts that *should* be able to use mail, but only about 50 that should
> not.  Our system would be a rightslist nightmare if we tried this.

We at Innosoft certainly agree that the present mechanisms in PMDF are not
terribly practical.  We've already implemented in PMDF V4.2 a new, more
practical mechanism.  We're also planning some new ACL based mechanisms since
VMS is moving more-and-more in that direction with new and improved ACL support
anticipated.

The input from the PMDF community has, as always, been quite helpful and was
what gave us the final nudge a few months back to implement the new support in
V4.2.

I shall summarize below the new support so that anyone spotting any missing
functionality, blunders, or whatnot can bring them to our attention now,
well in time for the next release.  And of course, further ideas are always
welcome.

The new support is implemented with a table in the mapping file.  Entries
in this table specify: the channel a message is coming from, the address of
the sender, the channel a message is going to, the to address, and finally
whether or not to permit the message to pass to the "to" channel:

    from_channel|from_address|to_channel|to_address     $Y/$N

Wild cards may be used for any or all of the first four items in an entry.
If a message is not permitted to pass to the to channel, then it is bounced
back to the from address.  Optionally, an error message to be returned with
the bounced message may be specified.

The ability to specify wild cards makes this facility quite flexible.  Clearly,
however, when there is no pattern to a set of to or from addresses requiring
access control, this scheme devolves to creating individual entries for each
address in that set.  It is here that ACL schemes or some other mechanism may
prove more apt.

Dan

----------------------------------------------------------------------------
>>         I'd like to be able to limit access to non-local (off-node) email.
>> I'm thinking that I can define a rights id, say 'NO_OUTMAIL' for example,
>> and set the appropriate image with an ACL such that anyone holding that id
>> cannot send internet mail messages.  My questions are simple:  Will this
>> work?  and, which image(s) should be set this way?
>
> This won't work since the users only run VMS MAIL or DECWindows MAIL.  They
> don't run the actual images which send outbound mail.  Instead, you probably
> want to associated this rightlist identifier with, say, your TCP/IP channel.
> You do this by merely specifying the rightlist id as a channel keyword; e.g.,
>
>         mtcp_local single smtp mx no_outmail
>
> Then, only processes with the no_outmail rightslist id can queue mail to
> the mtcp_local channel.  Be sure to grant this rightslist id to whatever
> accounts PMDF may run under!
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU