[Mailman-Developers] Soliciting feedback on idea for rounding out the permissions model.

[Stephen J. Turnbull]

Andrew Stuart writes:
 > >>>Are there any other permissions you can think of?

 > I figured that an archive, which isn’t really a Mailman resource
 > anyway(?),

Not in the sense that core can enforce any restrictions on archives.
Back in the bad old days, I had a ~/public_html and AltaVista crawled
right up to ~ and back down into my personal folders, to the great
shock of a coauthor who thought he'd only only shared his draft with
me.  Me, too.  While httpds got smarter than that after a while, it
would be quite easy for a malicious person or whistleblower to
subscribe and publish in many cases.

N.B. One of my Systers GSoCs wrote a "Mailman control panel" that gave
access to all Mailman features (posting, reading, archives, admin).
The current separation of user admin (both by admins and users
themselves) of the Big 3 components has never really sat well with me.

 > has the same permissions as the list that it gets its
 > emails from.

 > Are there any other Mailman resources beyond user, list, domain,
 > server?  There is member, but that is really more of a relationship
 > between a user and a list - not a standalone resource that requires
 > permissions - is that right?

In Mailman 2, and I believe in Postorius, there's a per-list setting
for whether one is visible as a member of a given list.  So yes,
membership is a resource.

 > As you've noticed, we have IMember objects which encapsulate the
 > list-centric roles for users.  It's important to note though that
 > this isn't quite complete because it's possible for validated,
 > non-user linked addresses to also be subscribed to mailing lists,

@Barry: Why?  Why not just make a dummy user for each such non-user?