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?