Stephen J. Turnbull writes > 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.
I understand that. > 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 do have other reasons, but I thought the once-in a lifetime change from Mailman2.1 will be the best time to do it. > We do not recommend running any distro's version of Mailman 3 at this > time. This argument is well-known and has been discussed here many times. > 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. I have used that when Debian testing updated the default python to 3.13 and Mailman was not ready for it. So your idea that distros are lagging is not always completely accurate. But anyway this has been discussed here many times. > > Is there an obvious way to do that? > > First, think twice about Odhiambo's suggestion of 'sed -e > s/OLD_dom/NEW_dom/', I already thought 3 times about it ;-) > because that will change the List-ID and message-ids. The most problematic aspect is that it may change the actual contents of the posts. > 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. I am astounded by this assertion. (1) As far as I understand, spam reputation is based on ip addresses, as they are the only thing in an email you can not fake. (2) the freemail providers' ways of running spam filtering appears very secretive. So while they may take account of a list-id, it's not usually known how and why. > 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 > > 1. read mm21 pickle to change the domains in it, write to temporary pickle > > 2. 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'; I am happy to read that what I think about here is not completely trivial. > 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. I don't know what the mail_host is. > > 3. 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. Hmm, you mean what users have in their archives on their computer? I have no write access to that. > If people are replying to messages in their own mailboxes > after the switchover, the breakage will propagate to your HyperKitty > archives. I doubt it. I intend to remove the mm21 list at migration time, so list@old_dom email will become unroutable, I suspect. This break in service is tolerable in my circumstances. All folks on the list know that I run them. They can email me personally to read me the riot act ;-) > 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. > > > 4. change the domainname in bodies and attachments (?) > > 5. 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. Thank you so much for your kind and detailed response. I ought to have specified that discontinuity of operation is not an issue in my specific circumstances. I will report on my progress. -- Written by Thomas Krichel http://openlib.org/home/krichel on his 22110th day. _______________________________________________ Mailman-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/[email protected]/message/ERTCHJT5RRFAK6IXTNDSWHN5WMGFVIR4/ This message sent to [email protected]
