Andreas Barth writes:
public: anyone can subscribe and read the archive.
This is already possible, more or less the default list configuration.
"Subscribe and read archive" involves multiple separate list attributes, enforced by three separate applications. Subscription policy is controlled by whether you need approval of an admin or not, and whether you need to verify your email or not, plus the ban lists. Archive access (assuming you have one at all) is contrlled by a different list attribute, archive_policy. Core has final say on subscriptions, but Postorius could do it if email subscriptions are disabled. HyperKitty handles the archive permissions. These various aspects are currently quite loosely coupled.
restricted: for employees (or members - or whatever) only. So they could subscribe themself. The archive and posting may be restricted to subscribers or to anyone in that group - both would be working for me.
I think this can be implemented with the controls we already have. The basic idea is to handle the "anyone in that group" case by mass subscribing and setting the subscription to no-mail. Obviously, this is most practical with a fairly static membership (eg, students at a school). A fluid membership (for example, a volunteer organization) would be made easier to manage with a "member adapter" to an external database to handle the "do I know this person" questions. ("Member adapter" is Mailman 2 terminology, I don't know if it's exactly the same in Mailman 3; it does or *should* exist in Mailman 3, though.)
It's possible that we could make this easier to configure with some changes to core. However, if this is as close to what you need as I think it is, I would advise against vendoring Mailman, and instead writing some scripts to help manage mass subscription, or create the member adapter.
(How to know who is allowed to subscribe is another question - having an internal mailing list which contains all the members just for this purpose would be ok for me.)
That's helpful to know. This sounds very similar to the Systers approach, where the Mailman core User database is the authoritative membership database for the organization.
private: hand-selected people, think about e.g. board or steering committees internal discussions. Of course, the archive (if there is any) should be restricted to the actual members. Posting to these lists is currently not restricted, so no derivation needed from the current set in postorius.
This is already possible by requiring admin approval, or by setting the ban list to something that matches everything like "^.".