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 > >