How about setting the instructor to being a member of the list instead of a
owner of a list.  Then set the review rights to only the postmaster or
postman of the system.  This should keep the instructors from being able to
do a review or get on the system.  If the instructors only want to send to
the list and not receive dailly information set them as a sender.  I think
that this is the simplist answer that I can come up with.  Once you get it
up and a few bugs worked out, the maintenance is really not that hard.  We
maintain rough 7,000 lists and only at the beginning of semesters is it
really a drain on our time.

Kevin.....





At 01:42 PM 10/15/98 -0400, you wrote:
>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
>
>