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

(info) If a CO Group is suspended, all of the associated CO Group Members are effectively removed for purposes of subscription synchronization

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

(info) If the status of the list is Suspended, the list will remain in place but all subscriptions will be removed

(warning) Renaming a list is not supported

Delete

Removes the corresponding Mailman list

Manual Provision

Synchronize the corresponding Mailman list, including subscriptions

Configuration

  1. This is a non-core plugin, see Installing and Enabling Registry Plugins for more information.
  2. Set up a Mailman3 installation. (Specifics are beyond the scope of this document.)
    1. 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. (warning) Be sure not to allow world access to the API.
  3. 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:

  1. If there is a configured preferred type and a matching email address of that type, that address is selected.
  2. Otherwise, select an address using the following type preference order:
    1. Mailing List > Delivery > Preferred > Forwarding > Official > Personal > Recovery > any other
  3. 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.


See Also