[MM3-users] Re: [Extern] Re: Moving lists to different server and domain

On Thu, Oct 29, 2026 at 2:31 PM Julian Kippels <kippels@hhu.de> wrote:

Am 29.10.26 um 12:25 schrieb Washington Odhiambo:

...

On Thu, Oct 29, 2026 at 12:41 PM Julian Kippels <kippels@hhu.de <mailto:kippels@hhu.de>> wrote:

Hi,

I want to move all my lists to another server. While I am doing

that, I

...

also want to change all lists from listname@domain.tld to
listname@lists.domain.tld

How would I best go about this? Will I have issues with the archives

of

...

the lists when the domain changes?

Thanks in advance,
Julain

Allow me to first ask: what is the reason for wanting to use lists.domain.tld? Is it to split mail routing away from the main domain’s MX?

[snip]

Historically I had users and mailinglists mixed together in the same namespace. This has grown a bit out of control and is really complicating things on the identity management side of things. I would like to have a simple route defined on my mta that sends everything from the new domain over to the new server instead of having to look up everything in LDAP all the time.

Julian

You just threw me off the cliff with that LDAP bit. Anyway, here is the process (ignoring the LDAP bit):

I'd strongly suggest doing this as two separate steps: move the server first with nothing renamed, verify everything works, and only then change the domain. If something breaks, you'll know which step caused it.

1. The server move (same domain)

Install the same versions of Mailman Core, Postorius and HyperKitty on the new server, then bring across:

• Both databases: the Core DB and the Django (mailman-web) DB.
• The Core var directory (list templates, held messages, queues, prototype archive).
• mailman.cfg, mailman-hyperkitty.cfg and settings.py. Keep SECRET_KEY, the HyperKitty api_key and the REST credentials unchanged.
• The full-text search index, or rebuild it afterwards with "mailman-web rebuild_index".
• Your web server vhost and MTA transport maps.

Run collectstatic/compress, test, then cut over DNS/MX. Upgrade versions only after the move works.

2. The domain change

Mailman 3 has no supported way to rename a list or move it to another domain. Maybe there is, but not off the top of my head right now. The list address lives in Core (mail_host, list_id, plus subscriptions and templates keyed by list_id), in HyperKitty (the list name, which is also in every archive URL), and in the Django mail domain/site records.

You have roughly three options:

1 - Create new lists and re-import (the clean, supported route)

• Create the domain lists.domain.tld.
• Create the new lists and copy their settings (scriptable via REST or "mailman shell").
• Export members with "mailman members -o" and import them with "mailman addmembers" (or mass subscribe in Postorius with invites off).
• Export each archive as mbox and load it with: mailman-web hyperkitty_import -l listname@lists.domain.tld archive.mbox then rebuild the index.

To answer your question directly: your archives will be fine. Old archive URLs will change, but HyperKitty's message and thread hashes are derived from the Message-ID, so they stay the same after re-import. A single redirect in your web server maps old URLs to new ones, e.g. in nginx:

 rewrite ^/archives/list/([^@/]+)@domain\.tld/(.*)$

/archives/list/$1@lists.domain.tld/$2 permanent;

Held messages, pending requests and per-member preferences (digest, nomail) won't carry over unless you script them, so clear moderation queues first.

2 - Rename in place via SQL Faster, but unsupported. You would update mail_host/list_id in Core, rename the template directories, then update the HyperKitty list name and the Django mail domain. It's easy to miss a reference, so only try this on a copy of the databases, and compare lists, rosters and archives before and after.

3 - Don't rename If the goal of lists.domain.tld is just to separate list mail routing from your main domain, MTA routing alone may get you there without touching the lists.

If you do change the domain:

• Set up MX, SPF, DKIM and DMARC records for lists.domain.tld, and check the PTR/HELO name on the new server.
• Keep listname@domain.tld forwarding to the new addresses for a few months.
• Warn subscribers that the List-Id is changing, since their mail filters keyed on it will stop matching.
• Check that accept_these_nonmembers and ban lists came across.

Hope that helps.

PS: You can always simulate things before the main shebang.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]