Mailman 3 March 2026 - Mailman-Developers

[GSoC 2026] Interest in User Profile Tool
by Rushikesh Bathe March 31, 2026

March 31, 2026

Hi, My name is Rushikesh Bathe, a third-year E&TC student from Sardar Patel Institute of Technology, Mumbai. I'm interested in the User Profile Tool for GSoC 2026. I setup Postorius , though the setup guide gave me some trouble on Ubuntu 24.04 / Python 3.12 — missing dependencies, broken requests_panel, NullMTA not mentioned anywhere. I have filed an issue for the same on mailman-suite-docs covering all the challenges i faced. After that went through views/user.py and had a few questions: 1. Preference handling is currently split across four views. Is the goal to unify them into a single interface, or keep them separate and just add a "map" view on top? 2. _get_combined_preferences() merges values but doesn't track which scope a value came from. Is source tracking what the "map" in the project description refers to? 3. There's a comment in UserMailmanSettingsView._get_preferences() calling the current approach "a bit of a hack" — is fixing that in scope for this project? My GitLab: https://gitlab.com/rushikeshbathe096 Thanks, Rushikesh Bathe

2 8

[GSoC 2026] Proposal Submission -User Profile Tool
by Rushikesh Bathe March 31, 2026

March 31, 2026

Hi all, I have submitted my GSoC proposal for the User Profile Tool project. I have also been working on related issues in Postorius and have opened a few merge requests: * postorius!1105 * postorius!1106 * postorius!1110 All of them are passing CI and are related to preference handling and UI improvements, which were confirmed by Steve so I have also included them into my proposal design. If you have some time, I would really appreciate it if you could review my proposal and share any feedback or suggestions for improvement as still I am making changes in my proposal. Sorry for any inconvenience, and thank you for your time. Best regards, Rushikesh Bathe

1 0

GSoC Merge Requests
by Stephen J. Turnbull March 30, 2026

March 30, 2026

Hi everyone I have reviewed everyone's Merge Requests that I could find for contributors who have already submitted a GSoC proposal. - If I approved any of your MRs, I tagged them "mergeable", then removed the "GSoC" tag from the rest and I probably did not review them. Those not reviewed remain assigned to me and we will review them in the near future (for more complex ones that may need to wait until community bonding period). - Otherwise I commented on all of them regarding the main issues that prevent approval at the moment. There were a few proposals submitted in the last 2 or 3 days. I'm not able to review them tonight, will do so in the morning or midafternoon (Japan time = UTC+9) tomorrow. I will be reading and responding to mailing list and personal email after that. Regards, Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 1

[GSoC 2026] Interest in working on issues #414 and #617
by Rushikesh Bathe March 27, 2026

March 27, 2026

Hi, While exploring some open issues, I came across #414 and #617 and would like to work on them. **Issue #617 — Multiple selection in non-members view** Looking at the code, the bulk action form and "select all" checkbox in `members.html` are gated to `role == 'member'` only. Extending both conditions to include `role == 'nonmember'` should show the UI for non-members too. On the view side, `_non_member_post` only handles adding a single member, so a bulk removal handler using `remove_role()` needs to be added, similar to how `_member_post` handles bulk unsubscription for members. Should bulk removal of nonmembers require a confirmation step, or just remove directly like members do? **Issue #414 — Allow un-setting a user's preferences** While working on issue #645, I noticed that `RESTDict.__delitem__` is already supported in mailmanclient, meaning individual preferences can be unset without any Core changes. My approach would be to add a "Reset to default" option per preference field — on POST, the key is deleted from the preferences object and saved, restoring inheritance from system defaults. Should this be per-field individual reset buttons, or a single "Reset all to default" for the entire form? Are these approaches correct and if yes can i open mr? Thanks, Rushikesh Bathe

1 0

[GSoC] Configurable Mail Footers - Implementation Approach and Few Questions
by Sambodhi Roy March 25, 2026

March 25, 2026

Hey Stephen, Here is my proposed approach and some questions as I am working on the proposal for "Configurable Mail Footers". The Implementation Approach I am planning on: 1. Update api_url to include $language as a placeholder and update get_template_data to accept it. With some preferred language -> English fallback inside Postorius, and 404 if English is also missing so Core continues up the list -> domain -> site chain. 2. Language will be optional so existing templates don't break. 3. A dedicated footer editor at list, domain, and site level with a language selector, plain textarea and reset-to-default. Live preview might be a stretch goal. 4. Tests for the fallback chain and permissions along with user documentation Here are a few questions I have: 1. Should the preferred language -> English fallback happen inside Postorius, or should core handle it? 2. Existing templates have an empty language field. Should empty mean English/default, or language-agnostic? This affects how we handle the unique constraint when new language-specific records are added alongside old ones. 3. A registered URL silently overrides any filesystem template the moment it is saved. Should the editor warn the admin when this is about to happen? 4. Should the new dedicated footer editor remove footers from the generic template dropdown to avoid confusion, or keep both working in parallel? Thank you Sambodhi

2 2

[GSoC] Implementing Domain Administration - Qeustions and Feedback
by khushal March 22, 2026

March 22, 2026

Hi, i was exploring the current Postorius code for domain and list permissions, and I wanted to know about few things before starting to plan the implementation. my understanding is that domain owners should be able to create lists only in the domains they own and for lists in those domains they should be able to do the same things as a list owner. I had a few questions about the expected behavior: i. should domain owner get all permissions as the list owner for the lists in their domain, or should some features still stay only with the list owners? ii. if domain owner creates a new list, should they be also added as an owner, or just domain level access enough? iii. in postorius, should domain owners have like a "domain page" where they see all of the domains they own? iv. can the domain owners modify domain level settings? v. is this the right heirarchy off permissions? site admin > domain owner > list owner > list moderator (shouljd domain onwers inherit all permissions of list owners??) thanks for your time Khushal (a-khushal)

4 5

Follow-up with the previous MR + GSoC proposal for dynamic Sublists
by Archie Singh March 22, 2026

March 22, 2026

Hi all, Thanks for the update wrt the MR for issue #1105 (I have also added the news item as suggested for the MR) and for the mailing list procedures, I will be providing full context for all my mails from here on out. > I don't understand why you think "keeping the Core API intact" is some thing that needs researching. (No reply needed if you agree it actually doesn't.) Earlier, I had been in the early stage of my research and had picked up the user profile tool project idea (as it felt close to the unsubscribing of alternative verified emails issue that I worked on for the MR), this point about the core API is what made me rethink the project choice (about how much backend work was needed etc.) and I think I had either misunderstood the project or thought of something else entirely. For the *Dynamic Sublists (Conversations) project idea*, it would be great to convert mailman into an opt in model from a broadcast model (like currently there is some inbox flooding for those working on a project idea who are getting conversations of other projects, like there should be something for them to opt out of some threads based on their area of interest) I have set up a public draft for my (GSoC) proposal on GitHub pages for your ready reference here (and as was suggested to me as feedback): https://archie-2006.github.io/2026/03/14/Dynamic-Sublists.html I have not currently finalised some aspects of the architecture (and even the time required, as it is stated on the mailman project ideas website for ideas that the time was dynamic and we could ask the mentors if there were any additional functionalities to be added) - does the “additional functionality” (for the 350 hour work progress) you are referring to involve integrating the web ui via hyperkitty and modelling the rest api endpoints while the earlier 175 hour implementation only involve core backend? And what should I be feasibly aiming for? - regarding database modelling, in my proposal i have suggested (a new sqlalchemy model) to use a root message-id for each of the threads, to track a user’s subscription to that thread/conversation, do you suggest that i link the conversation thread directly to the user object or the (email) address object (as one user can hold multiple addresses although they might be using different addresses to start different conversations as a form of pseudonym (i thus believe linking threads to addresses is a more practical choice)). But I would still want your input on this… - as the email passes through different handlers, there are many checks assuming spam check moderation, recipients (where the email addresses of every single person subscribed to the list gets their email addresses extracted) etc. although for this project regarding conversations, if someone replies to a thread the email should not be going out to all the people but only the people who are following this conversation. So, there should be a custom handler (to overwrite the recipients dictionary) that is injected in the middle of the pipeline; now the problem I am thinking of is, if the custom handler is added too early it might bypass some safety or spam checks, and if it’s too late then the mail would already be sent out…so a consequent question arises, is there a preferred stage in the delivery pipeline where I should be placing this custom handler? I think it should be placed before the handler to_outgoing (which basically just takes the email, checks the recipients of the mails dict and sends the emails out), this being after all the safety checks have passed. Thank you so much for your time Regards Archie

2 6

[GSoC] Topics feature - implementation approach and a few questions
by khushal March 22, 2026

March 22, 2026

Hi, from what I understand, the idea is that list admins can define topic tags, and members can subscribe only to the topics they care about. If a message has a topic assigned then it will only go to members subscribed to that topic. the direction in which i'm thinking, - the topics are defined per mailing list by admins - members can subscribe/unsubscribe from topics - messages can be tagged with a topic - during delivery, Mailman checks the message topic and only sends it to members subscribed to that topic - untagged messages treated as the special "not a topic" Questions: i. does "not a topic" mean messages that don’t have any topic assigned? ii. if a member is not subscribed to any topics (including "not a topic"), should they receive no messages at all? iii. fro the scope of the project, is Core + Postorius support main expectation, and wiht email commands as an additional goal? iv. for adding topics to messages does this happen only though Postorius or should topic headers in incoming mail must be also supported? thanks for your time Khushal(a-khushal)

4 16

Re: Merge requests scheduled for review
by Navya Khanna March 22, 2026

March 22, 2026

>> Mailman core: >> !1438 >> !1439 >> !1445 >> !1449 >> !1451 >> > !1453 > >> !1454 >> !1458 >> !1461 >> !1462 >> >> Postorius: >> !1063 >> !1064 >> !1065 >> !1074 >> !1075 >> !1077 >> >> HyperKitty: >> !701 >> !702 >> !703 >> !704 >> !705 >> >> >>

3 4

[GSoC 2026] Proposal submitted — Dynamic Sublists
by Tejas Pavan B March 22, 2026

March 22, 2026

Hi Stephen and all, I have submitted my GSoC 2026 proposal for Dynamic Sublists on the Google Summer of Code site. The proposal title is "Dynamic Sublists for GNU Mailman 3". I have submitted it as a Large (350 hours) project, covering mailman-core, Postorius, and HyperKitty — please let me know if you would prefer a different size. I have also updated both open MRs based on your feedback: - mailman-core !1459: Added NEWS item and updated help text to include that 'mailman stop; mailman start' should restart dead runners. - mailman-core !1458: Added NEWS item and improved the test to verify that Postfix transport map files (postfix_lmtp, postfix_domains) are actually updated after domain deletion — not just that remove_list was called. Looking forward to your feedback on the proposal. Tejas Pavan B gitlab.com/tejaspavanb https://gitlab.com/mailman/mailman/-/merge_requests/1459 https://gitlab.com/mailman/mailman/-/merge_requests/1458

2 1