The Mailman Provisioning Plugin manages Mailman3 mailing lists using Registry data.
This Plugin currently requires specific patches against the Mailman3 codebase in order to function correctly. As such, it is considered Experimental.
Operations
Registry CO Person Transaction | Changelog Action |
|---|---|
Add | Synchronize the CO Person and their Mailman list subscriptions |
Edit | Synchronize the CO Person and their Mailman list subscriptions (this includes CO Group Membership changes) |
Enter Grace Period | No changes (unless attributes change as part of grace period) |
Expiration / Becomes Inactive | Unsubscribe the CO Person from Mailman lists |
Unexpire / Becomes Active | Synchronize the CO Person and their Mailman list subscriptions |
Delete | No changes (subscriptions will be removed due to loss of CO Group Memberships) |
Manual Provision | Synchronize the CO Person and their Mailman list subscriptions |
Registry CO Group Transaction | Changelog Action |
|---|---|
Add | No changes |
Edit | No changes
|
Delete | No changes |
Manual Provision | No changes |
If a CO Group is suspended, all of the associated CO Group Members are effectively removed for purposes of subscription synchronizationRegistry CO Email List Transaction | Changelog Action |
|---|---|
Add | Create a corresponding Mailman list, and synchronize subscriptions |
Edit | Synchronize the corresponding Mailman list, including subscriptions
|
Delete | Removes the corresponding Mailman list |
Manual Provision | Synchronize the corresponding Mailman list, including subscriptions |
Configuration
- This is a non-core plugin, see Installing and Enabling Registry Plugins for more information.
- Set up a Mailman3 installation. (Specifics are beyond the scope of this document.)
- The Provisioner requires access to the administrative REST API. By default, this API is only available on
localhost:8001, so you will probably need to make some changes so that your Registry server can speak to it. (If you don't, you may need to specify 127.0.0.1 rather than localhost.) Possible approaches include reconfiguring the mailman REST web server to allow connections from your private network, or setting up a secure tunnel of some form.
Be sure not to allow world access to the API.
- The Provisioner requires access to the administrative REST API. By default, this API is only available on
- Provide the appropriate configuration information. After clicking Save, the configured domain will be created if it doesn't already exist.
Preferred Addresses
COmanage create a Mailman user for each provisioned CO Person, and then subscribes that user to the relevant Mailman lists. In order for this to work, the Plugin must determine a preferred address for each CO Person. The preferred address is determined by:
- If there is a configured preferred type and a matching email address of that type, that address is selected.
- Otherwise, select an address using the following type preference order:
- Mailing List > Delivery > Preferred > Forwarding > Official > Personal > Recovery > any other
- If there is more than one active address of the selected type, select the address with the lowest internal ID (typically the oldest).
Verified status is currently ignored when selecting the preferred address.
Important Constraints
- An address can only be attached to one Mailman user, so if for some reason an address is registered multiple times, only one Mailman user can have it.
- A CO Person can only have one active address, since the preferred address is used for Mailman message delivery.
- Mailman Users span domains, so in a multi-tenant instance (or a single tenant instance where more than one provisioner is configured to provision more than one domain), each tenant will likely require its own mailman server, not just its own domain.
- Renaming a list is not supported. Changing the list name in COmanage will not change the list name in Mailman.