[GSoC 2026] [Feature Proposal] Per-List Backup and Restore Support
*Introduction: *
My name is *Sonika Chowdary Gutha*, and I am a *second-year Computer Science undergraduate at BITS Pilani, India*. I recently completed a *6-month internship in Backend Development using Python and Django*, where I gained experience in building backend systems and working with REST APIs.I am also familiar with the *MERN stack and the Flutter framework*, and I have experience developing both web and mobile applications. In addition I have been introduced to the fundamentals of several programming languages, including *Python, C++, and JavaScript*.
I am exploring the possibility of implementing a *per-list backup and restore feature* for Mailman. The goal of this feature is to allow list administrators or owners to *export the configuration and membership data of a specific mailing list into a portable backup file and restore it later when needed*.
This could be useful in situations such as:
Migrating lists between servers
Recovering from configuration mistakes
Replicating list setups across environments
*Implementation:*
The following diagram provides a visual representation of the proposed backup and restore workflow <https://excalidraw.com/#json=PhUB9tdMrupMfpx7O6_i6,OLBUtBJjL5_sCR-UokrNHw> .:
I plan to implement this feature in two parts. The main backup and restore logic should live in *Mailman Core*, since that is where the actual list configuration and membership data are stored. My idea is to define a *versioned JSON format* that captures the important per-list data such as list settings, members, owners, moderators, and relevant subscription preferences. On the export side, Core would gather this data and write it into a portable backup file. On the restore side, it would read the file, validate its contents, recreate the list if necessary, and restore the saved settings and memberships.
On the *Postorius* side, I would implement the user-facing workflow for this feature. This would include an option for list owners or administrators to download a backup file for a specific list, as well as a page where they can upload and restore that file when needed. For the initial version, I plan to keep the feature focused and reliable by covering configuration and membership data first, while leaving more complex areas such as archives or other external components out of scope unless they are explicitly expected.
*Questions:*
For the first version, what exactly should be included in the per-list backup: only settings and memberships, or also items like templates, ban lists, and member preferences? 2.
Should the main export and restore implementation live in Mailman Core, with Postorius mainly responsible for the UI and workflow? 3.
Is a *versioned JSON format* the preferred choice for the backup file? 4.
Should restore only support creating or recreating a list from backup, or should it also support restoring into an already existing list?Thank you for your time and feedback.
Please feel free to *suggest any changes or improvements to the proposed implementation*, also if possible hope i can get answers for the above questions which will be helpful for my proposal, I would be happy to incorporate them.:)
Best regards, Sonika
Hi Sonika
I am cross-posting and setting Reply-To to mailman-developers. People who want to discuss the user experience for this feature are welcome to override and continue here, but the primary purpose of this thread seems to be implementation, so mailman-developers seems more appropriate.
You're welcome to post here, but most implementation discussions are taking place on mailman-developers@python.org. The advantage to posting here is primarily when you are hoping for information about how popular a feature is, or what users (mostly admins) think about a design choice that affects the user experience.
sonika gutha via Mailman-users writes:
I am exploring the possibility of implementing a *per-list backup and restore feature* for Mailman.
This has been recently requested and seems plausible in general.
I plan to implement this feature in two parts. The main backup and restore logic should live in *Mailman Core*, since that is where the actual list configuration and membership data are stored.
Besides marshaling the information and serializing it to JSON, I think that the initial UI implementation should be done in the mailman utility. The issue is that some of the use cases involve security or reliability issues. For example, consider cloning a list configuration to a new list. This should be restricted to the superuser or domain owners, as others are not allowed to create new lists. Another example, if a list is backed up, and then accidentally deleted, it's possible that the member lists contain addresses that have been deleted. Cleaning that up may require superuser privileges.
My idea is to define a *versioned JSON format* that captures the important per-list data such as list settings, members, owners, moderators, and relevant subscription preferences.
Subscription preferences need care, because they are the property of the subscriber, not the list administrator.
while leaving more complex areas such as archives or other external components out of scope unless they are explicitly expected.
Backing up archives is definitely out of scope. I'm not sure what other "external components" you have in mind.
*Questions:*
- For the first version, what exactly should be included in the per-list backup: only settings and memberships, or also items like templates, ban lists, and member preferences?
Everything accessible from the REST API, as much as possible. Web templates are usually customized in files in the /etc/mailman3 hierarchy, and are site-wide, so those are not in scope.
- Should the main export and restore implementation live in Mailman Core, with Postorius mainly responsible for the UI and workflow?
Yes. These functions need to be accessible from the mailman utility, as there is no guarantee that Postorius is available.
- Is a *versioned JSON format* the preferred choice for the backup file?
By "versioned", do you mean the *format* is versioned, or the *backup* is versioned? In general, I think formats should be versioned because it's cheap to do so and may help in debugging. The backup should be versioned with the SQLAlchemy database schema, and also timestamped. For most use cases, the timestamp is most relevant, but for an old enough backup the database schema could change and should be checked.
- Should restore only support creating or recreating a list from backup, or should it also support restoring into an already existing list?
It should be possible to overwrite settings in an existing list, for example in case of accidental changes, or to share ban lists and templates. Note that this implies partial restores, but that's not in scope for the moment.
The specific use case recently requested was an organization that wants to implement a policy of being able to restore a deleted list for a certain period of time in case there are regrets.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thank you Stephen, this is very helpful.
I understand that the implementation discussion is better continued on mailman-developers, and that mailman-users is more appropriate for feedback about user experience and feature demand.
Your guidance on scope and architecture is especially useful. My current understanding is:
- the backup/restore logic should live in Mailman Core
- the initial interface should be exposed through the mailman utility
- Postorius, if added, would come later as an additional UI
- the backup format should be versioned and include metadata such as timestamp and schema compatibility
- archives and site-wide web template customizations are out of scope for the first version
- subscription preferences and restore permissions need special care
I will refine the proposal in that direction and continue the implementation discussion on mailman-developers.
Thank you again.
participants (2)
-
sonika gutha -
Stephen J. Turnbull