I've moved lists and archives between domains in Mailman 2.1 and Pipermail, but not yet with Mailman 3 and Hyperkitty.
I have a working multi-domain deployment, and one of the organizations using it is working on changing their domain name. Forwarding incoming messages at the MTA and setting up redirects on the Web server are simple enough, but internally within MM3/Django reside the bits I'm less certain about.
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries. Is there anything outside the DB which would need updating or regenerating for this too? Is this how others have tackled similar tasks in the past, or is it recommended to export/import lists one at a time out of one domain and into another?
Any tips are greatly appreciated!
Jeremy Stanley
On 9/18/24 10:13, Jeremy Stanley wrote:
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries.
Yes.
For the mailing list, the only changes needed are to the mailinglist table; A query like
UPDATE mailinglist SET mail_host = 'new.domain' WHERE mail_host =
'old_domain';
would do, but this leaves the question of list_id. According to RFC 2919, section 4, the list_id should not change, but this is problematic in that if it isn't changed, a Postorius URL like https://example.com/mailman3/lists/list_name@new.domain will retrieve the list, but https://example.com/mailman3/lists/list_name.new.domain will not work. It would need to be https://example.com/mailman3/lists/list_name.old.domain so to reduce confusion, it may be better to update the list_id values
A query like the following after the above should do it
UPDATE mailinglist SET list_id = CONCAT(list_name, '.', mail_host) WHERE
mail_host = 'new_domain';
For HyperKitty, similar changes need to be made to the
hyperkitty_mailinglist table. The name
column entries need to be
changed from listname@old.domain
to listname@new.domain
and the
list_id
column entries need to be changed from listname.old.domain
to listname.new.domain
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2024-09-18 16:36:50 -0700 (-0700), Mark Sapiro wrote:
On 9/18/24 10:13, Jeremy Stanley wrote: [...]
Since all the lists for the given domain will be moving to the same unused new domain on the existing server, and can move at the same time, I suppose this could be done through (offline if necessary) backend database update queries. [...] For the mailing list, the only changes needed are to the mailinglist table; but this leaves the question of list_id. According to RFC 2919, section 4, the list_id should not change, but this is problematic in that if it isn't changed, [...] so to reduce confusion, it may be better to update the list_id values [...] For HyperKitty, similar changes need to be made to the hyperkitty_mailinglist table. [...]
Thanks! This looks even more straightforward than I'd hoped.
-- Jeremy Stanley
participants (2)
-
Jeremy Stanley
-
Mark Sapiro