The Mailman Provisioning Plugin manages Mailman3 mailing lists using Registry data. (experimental)
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 | Mailman 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 | Mailman Action |
---|---|
Add | No changes |
Edit | No changes
|
Delete | No changes |
Manual Provision | No changes |
Registry CO Email List Transaction | Mailman 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.
Unmanaged Email Addresses
Email addresses may be subscribed to a mailing list outside the control of COmanage Registry, for example by a Mailman administrator using the native Mailman web administration tool Postorius. When Unmanaged Email Mode is set to Remove (the default), the provisioner will remove any such unmanaged email addresses from the mailing list when the list is synchronized. Set Unmanaged Email Mode to Ignore to have the provisioner ignore unmanaged email addresses for a list when synchronizing the memberships.
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.
- Registry assumes it has full management of Mailman Users. If an email address is directly added to Mailman, and that email address is subsequently added to a Registry record that is then provisioned to Mailman, the provisioning action will fail, since Mailman will indicate that the address already exists (but Registry won't have any knowledge of it).
- Registry may not be able to delete a mailing list if Unmanaged Email Mode is set to Ignore and unmanaged emails are members of the list at the time Registry attempts to delete it.
- Renaming a list is not supported. Changing the list name in Registry will not change the list name in Mailman.