On Fri, 19 May 2006, Brad Knowles wrote: > At 3:19 PM +0100 2006-05-19, David Lee wrote: > > > But then the potentially useful moderation-bypass "Approved: listpw" > > mechanism has the problems of requiring many people to share a particular > > list's password, > > Yup. > > > and of the passwords across a cluster of lists having to > > be common. > > I'm not convinced that's necessary. Each list could have their > own approval password, and there is no technical reason why they > would need to share that password with any other list.
One of our site's uses is people in the top-level management of the university sending out an email (a few per week) to a set (order ten) of announcement lists. The set of lists might vary from email to email (e.g. email-1 about exams to the all student lists; email-2 about marking to to the academic-staff list and to the secretarial list; email-3 about holiday cover to all the staff lists). From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], ... [EMAIL PROTECTED] My understanding is that to get this email straight through using the "Approved:" mechanism all those lists (i.e. their superset) would currently need to share a common password. (I haven't seen documented the ability to have multiple one-per-list, "Approved:" lines.) If I've misunderstood this functionality (i.e. perceived limitation) please let me know... it's central to what I'm looking for! And then there might be another cluster of announcement lists, say within a particular department, with a basically different set of people who would post, and so with a different password on their lists. But it might be highly desirable to permit occasional posting by a subset of the former (top-level management) group of people. They certainly won't want to have to know those (different) list-based passwords for the list clusters in and across every department! > That said, there may be operational reasons why you might end up > going down this road, such as people not being good at remembering > large numbers of passwords. Hence my suggestion of a person's (single) personal "sender" password into the overall system, entitling them to send to those Mailman lists whose "authorised_senders" includes them. This might be viewed as (very roughly) analogous to single sign-on. On the big, university-wide lists, the "authorised_senders" group would typically be the university's top-level management, and people such as "postmaster". On the departmental lists, "authorised_senders" might be several (all?) staff in the department, perhaps occasional guests, and (again) some (all?) of the university's top-level management. Does that help. > Beyond that, I'm not sure that I can contribute much of anything > more to this discussion. Simply sanity-checking my reasoning from your experience of mailman. (Whether you agree is another matter!) Until three weeks ago, I had never run a mailman installation, so I feel like a fish almost out of water. Thanks. Best wishes. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
