Thomas Krichel writes:
I want to migrate mm21 to mm3, by changing the domain of the list, thus LIST@OLD_dom to LIST@NEW_DOM.
Are you changing the domain *because* you're upgrading Mailman? There's usually no need to do that. There are several ways to ensure continuity of operation during the switchover. Of course if you have other reasons to change the domain, that's your business and I don't need to know why (just that you do have reasons).
I run on debian, with the debian testing version of mm3 installed.
We do not recommend running any distro's version of Mailman 3 at this time. Mailman development is not of the "move fast and break things" ilk, but all of the major distros are out of date by the time they get Mailman into "testing" or the equivalent for non-Debian distros. It makes it harder for us to support you. See https://docs.mailman3.org/en/latest/install/virtualenv.html for the preferred installation approach. That makes it much easier for you to upgrade in the event of a security patch or new feature you want.
Is there an obvious way to do that?
First, think twice about Odhiambo's suggestion of 'sed -e s/OLD_dom/NEW_dom/', because that will change the List-ID and message-ids. Usually it is recommended to keep the List-ID. Among other things, keeping it will help establish the reputation of the migrated list with the more professionally-run freemail providers. Since message-ids as data are spread across subscribers' mailboxes, you really don't want to change those.
Right now I think 0. create new list
- read mm21 pickle to change the domains in it, write to temporary pickle
- run mailman import with that pickle
The issue of changing domains "forward" (= for future posts) came up earlier, and Mark recommended using the database's command line utility to change the list's mail_host entry:
I don't have much experience with this, but I think just something like this database query will do it UPDATE mailinglist SET mail_host = 'NEW_dom';
If so, the better strategy is to just import the old pickle, then change the associated mail_host. This leaves the list_id the same, which you probably want.
- read the archive mailbox and change the domain in all the headers
This will break threads and archive pointers in members' personal archives if you change the Message-ID, In-Reply-To, or References headers. If people are replying to messages in their own mailboxes after the switchover, the breakage will propagate to your HyperKitty archives.
Note that HyperKitty doesn't care what the domain name of the archive host is when serving a list. It's perfectly happy to serve any number of domains. If it was designed properly (I think it was but not 100% sure), continuity of each list's archive is based on the list_id, not the posting address. The same is true of threading, it's based on chaining Message-IDs via References and In-Reply-To headers, not the posting address.
- change the domainname in bodies and attachments (?)
- run hyperkitty import
This may be the project of a madman... any advice?
Before you go messing with the data of the old list configs and archives, consider that most of the mechanisms that provide continuity in the archives don't depend on the list posting address. There's nothing you can do about people who are replying to old messages in their local mailboxes. So if possible, you probably want to keep the old address as a CNAME or MX in DNS at least for a while, and perhaps have the MTA rewrite the list-post address of new posts to the list before distribution. That approach is much less likely to cause discontinuities in list operation.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan