Off the top of my head:
I'd only have one mailing list; the sublist/superlist setup shouldn't be
necessary. The key things are:
1) The instructor shouldn't be a listowner. (It may be appropriate to have
him or her be an editor or a moderator, depending on who's supposed to be
sending mail to the mailing list.)
1) On the mailing list, set * Review= Private
2) On the sublist, set all of the private subscribers to have the CONCEAL
option set. (SET listname CONCEAL for user@node)
If you already have a list of the private users' email addresses, you can
use that; otherwise, you can get a list of these users by issuing a 'SCAN
listname PRIVATE'.
3) Make sure that the instructor him/herself is a subscriber to the
sublist. (He or she can be set to be nomail.)
The CONCEAL option prevents the user from showing up on REVIEW commands
(unless the command is issued by a listowner), so this should do it.
A side-effect of this setup is that other students on the mailing list will
be able to get a list of other non-concealed subscribers. I don't know if
that's a problem or not, or if there's a policy on such things. If it is,
there may be other * Review= options that plug this hole; see the manual
(or the LISTKEYW MEMO file) for more information on how this can be set up.
Even if this isn't how you end up setting up your mailing lists, I hope
these suggestions are of some help.
-jwgh
>Hi folks,
>
>I find myself in a bit of a pickle and am looking for some
>suggestions.
>
>My situation is as follows:
>
>We have for years now, automatically subscribed students to their "class
>mailing lists" and their respective "yearly mailing lists". At
>registration, students can indicate whether they want their e-mail address
>to be published (on our public ph server, etc.). The program that
>feeds Listserv the student names and e-mail addresses for these lists
>grabs ALL students from our registrar's database. If a student indicated
>that they wanted their name and e-mail address to be private, the word
>PRIVATE appears after their name when an instructor does a REVIEW of their
>list.
>
>The problem:
>
>A new administration policy governing access to student information is
>forthcoming which will prohibit an instructor who owns a list from having
>access to the list of students subscribed. In order to be in compliance
>with this new policy I thought I could create a Super List for the
>instructor that he or she would own and use a Sub-List=xxxxx-s for
>students I add which the instructor would not own. For the record, I
>don't think it is appropriate that an owner of any list should be
>restricted from the subscriber list, but my hands are tied. At any rate,
>instructors have been informed, and they are furious because they use
>their class mailing lists in ways unanticipated by management which
>requires access to their subscriber list (a long story left out here).
>
>I have been asked to explore other technical solutions that would keep
>everyone happy and be in compliance with new policy. I can only think of
>three solutions when I rack my brain, and I don't think the first two are
>possible without access to Listserv's source code and I don't like the
>third. They are:
>
>1. Find a way for Listserv, when presented with a REVIEW request for these
>lists, to parse the subscriber list and omit any entry with the word
>":PRIVATE:". (This will leave the instructor with access and the
>instructor can operate as before with limited REVIEW output.)
>
>2. Find a way for Listserv, when adding subscribers, to parse the
>name field, and when finding the word :PRIVATE:, add this student
>to the sub-list=xxxx-s while adding others to the super list. (SAA)
>
>3. Move all student mailing lists from Listserv to Graffitti (the latter
>is a home grown chat for courses with a web interface; hardly as
>functional as Listserv.).
>
>Any ideas about how I could do 1 or 2 above or has anyone else been in
>a similar situation and is willing to share their solution? Thanks
>for your time.
>
>--Trish
>-------------
>Trish Forrest
>ITS - Queen's University
>545-2014
|
