On 1/13/2026 10:46 AM, Stephen J. Turnbull wrote:

dap1--- via Mailman-users writes:

...

How do I manually change a member's address? I can't find any way to do that from the mailman-web pages. Do I need to do it within MySQL somewhere? TIA.

Log in as superuser (list owner does not allow you to manage users), click on the the Users tab (this is visible on the list of lists page; the Users menu for the list itself does NOT provide the "manage user" functionality), find the User for the member in question, and click the Manage button on the right hand side.

You could also do it with "mailman shell", but I don't know the exact APIs.

It *may* be possible to do with naive SQL queries but I'm not sure about that -- there are various relations and indicies you may to update as well, and you have to know the ins and outs of the tables because there isn't a straightforward user record with a text record for "email". An Address is not just a string, and the User-Address relation is one-to-many. All that is managed automatically by the Python models in Mailman.

I can't seem to confirm the superuser's email address. I get the confirmation link and when I click it, the confirm button shows up. However, when I click confirm it immediately goes to the login page and when I try to login it sends another confirmation. Its an unending loop.

On 1/14/2026 1:41 AM, Stephen J. Turnbull wrote:

Dennis Putnam via Mailman-users writes:

...

I can't seem to confirm the superuser's email address.

Find the address in both the account_emailaddresses table and the addresses table. I'm interested to see the full record for both (you can obscure the email and display_name for this purpose). This is in the interest of figuring out why you are inflooping in the confirmation process. From database mailmanweb:

mysql> show tables; +-----------------------------------+ | Tables_in_mailmanweb              | +-----------------------------------+ | account_emailaddress              | | account_emailconfirmation         | | auth_group                        | | auth_group_permissions            | | auth_permission                   | | auth_user                         | | auth_user_groups                  | | auth_user_user_permissions        | | django_admin_log                  | | django_content_type               | | django_mailman3_maildomain        | | django_mailman3_profile           | | django_migrations                 | | django_q_ormq                     | | django_q_schedule                 | | django_q_task                     | | django_session                    | | django_site                       | | hyperkitty_attachment             | | hyperkitty_email                  | | hyperkitty_favorite               | | hyperkitty_lastview               | | hyperkitty_mailinglist            | | hyperkitty_mailinglist_moderators | | hyperkitty_mailinglist_owners     | | hyperkitty_profile                | | hyperkitty_sender                 | | hyperkitty_tag                    | | hyperkitty_tagging                | | hyperkitty_thread                 | | hyperkitty_threadcategory         | | hyperkitty_vote                   | | postorius_emailtemplate           | | socialaccount_socialaccount       | | socialaccount_socialapp           | | socialaccount_socialapp_sites     | | socialaccount_socialtoken         | +-----------------------------------+ 37 rows in set (0.00 sec)

The table account_emailaddress has 3 entries:

mysql> select * from account_emailaddress; +----+-----------------------+----------+---------+---------+ | id | email                 | verified | primary | user_id | +----+-----------------------+----------+---------+---------+ |  1 | uuuu@ddddddddd.net    |        1 |       1 |       2 | |  2 | uuuu@ddddddddd.net    |        0 |       0 |       3 | |  3 | xxxxxxxx@gmail.com |        1 |       1 |       4 | +----+-----------------------+----------+---------+---------+ 3 rows in set (0.00 sec)

Yes, id 1 and 2 are the same email address.

From database mailman:

mysql> show tables; +--------------------+ | Tables_in_mailman  | +--------------------+ | _request           | | acceptablealias    | | address            | | alembic_version    | | autoresponserecord | | ban                | | bounceevent        | | contentfilter      | | domain             | | domain_owner       | | file_cache         | | headermatch        | | listarchiver       | | mailinglist        | | member             | | message            | | onelastdigest      | | pended             | | pendedkeyvalue     | | preferences        | | template           | | uid                | | user               | | workflowstate      | +--------------------+ 24 rows in set (0.00 sec)

I'm not sure what you want to see in this address table. There is a lot of unexpected email addresses that I have no idea where they came from. In any case the user_id in this table does not correspond to the user_id in the table from the previous mailmanweb table. Here are the columns:

+----+---------------------------------------------------+-----------+------------------------+---------------------+---------------------+---------+----------------+ | id | email                                             | _original | display_name           | verified_on         | registered_on  | user_id | preferences_id | +----+---------------------------------------------------+-----------+------------------------+---------------------+---------------------+---------+----------------+

Confirmation you can do with a single SQL update. Find the address in the account_emailaddresses table and update the verified attribute to t. I think that's enough to allow you to log in. If not you should do the same for that address in the addresses table. However, in the addresses table you need to fill the verified field with a timestamp. Not sure how that works in SQL, try copying the value of the registered field.

I don't know why you're inflooping though. It's possible that you're verified in one table but not the other, confusing Postorius.

https://whatever/django/auth/user/ page not found

On January 15, 2026 8:54:27 AM PST, dap1--- via Mailman-users <mailman-users@mailman3.org> wrote:

https://whatever/django/auth/user/ page not found

My bad. As Odhiambo says, those URLs should be https://whatever/admin/..., not https://whatever/django/...

-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

I got a different user set up as superuser using a gmail address. However, I get to the member's management page but cannot change anything. I see update buttons but they don''t seem to so anything although I get a banner at the top saying the user was updated. What am I doing wrong?

On Tue, Jan 13, 2026 at 11:14:04AM -0800, Mark Sapiro wrote:

...

...

...

um = getUtility(IUserManager) addr = um.get_address('address_to_change') addr.email = 'new_address' commit()

However, the preferred way is for the user to log in, go to
https://whatever/accounts/email/, add the new address to their account, make
it primary, go to the list info page at https://whatever/lists/LIST, and if
their Subscription Address is still the old address (because they weren't
subscribed by primary address), click Manage Subscription and change it, and
then possibly remove the prior address.

That should be trivial for any user to do that - certainly I, and others on this list, would not have a problem. However: many of my users would find those instructions baffling, they can just about manage email - on a good day.

Like it or not it is sometimes easier for me to do that sort of thing than try to explain it to them. In the past I have done it by running up MySQL and hacking the table directly.

I host several mail lists, some of which I do not manage - my 'clients' do that and, with a bit of hand holding have learned to add/remove/... people to lists via the web interface. They do not know what the mailman shell is - and I would not want to give them shell access to the machine.

So: it would be really useful if the list manager were able to do this via the web interface.

Please!

-- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

alain williams writes:

I host several mail lists, some of which I do not manage - my 'clients' do that and, with a bit of hand holding have learned to add/remove/... people to lists via the web interface. They do not know what the mailman shell is - and I would not want to give them shell access to the machine.

So: it would be really useful if the list manager were able to do this via the web interface.

I would oppose this. User email addresses have to be mutable by the user, but the list manager's interest in them is very limited. The potential for screwing up other lists is large. You are requesting this because the users don't know what they're doing. In that case they may be displeased with the result, which will require other list managers to fix problems you've created. On the other hand we could restrict the effect to the particular subscription, but that would entail other issues.

I'm pretty sure allowing list administrators to manipulate user addresses would be a vector for social engineering to take over an account, as well. Not that taking over a Mailman account is particularly valuable to hackers, but I've seen people do similar things purely out of malice.

I would support a merge request allow exporting and importing a user's option configuration via a file in a JSON or TOML format (ie, no PII).

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

I think we can wrap this up. Magically the original superuser is now showing confirmed and seems to work. The only remaining issue is the from header showing up as lllllllll.bounces rather than just llllllll.

dap1--- via Mailman-users writes:

Stephen: I will be collecting the information requested. However, the address "xxxxxxxx" is the superuser that lets me log in. "uuuu" is/are the address of the superuser I can't confirm.

Usually there's only one superuser account. There's no reason not to have more than one. Caveat, I've always used SQL UPDATE to toggle the superuser and staff bits on an existing account. But I would imagine using createsuperuser to make the additional superuser accounts would work as well. I do not understand how you created two instances of the "uuuu" address and linked user accounts. Maybe there's some kind of race condition

It does not appear that "uuuu" is in the address table.

That's definitely possible. It's probably just because it's never been used to attempt to post or be a member (including owner or moderator) of a list. Mailman core manages that table. I don't think Postorius updates it except as a side effect of creating list members, which is does through a proxy object which manages a core User object accessed via the REST API.

As for the unexplained addresses in there, mailman2 does not use mysql, does it?

No, Mailman 2 does not use SQL. But if you ever tried to migrate the list, the mailman2 addresses and subscriptions would be in Mailman 3's MySQL database until explicitly deleted or the database dropped, even if you deleted the original Mailman 3 installation and reinstalled.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan