moving individual list to different domain
Dear all,
on mailman2 it was possible to move a list to a different domain within the same mailman instance.
I have found no information on how the same can be accomplished on mailman3.
Is this possible at all?
Thanks!
Johannes
On 3/21/23 06:21, Johannes Rohr wrote:
Dear all,
on mailman2 it was possible to move a list to a different domain within the same mailman instance.
I have found no information on how the same can be accomplished on mailman3.
Is this possible at all?
In mailman 2.1, a list was identified by its name only without the domain and those names had to be globally unique. A site could be configured to support multiple virtual hosts and a list had a host_name attribute which could be changed if desired to assign the list to a different virtual host, but there couldn't be two lists with the same name even if they had different host names.
Mailman 3 is different. In order to remove the restriction that list names (without the domain) had to be globally unique, in MM 3 the domain is part of the list name. I.e., we can now have list@example.com and list@example.net as two distinct lists in the same installation.
Suppose we want to rename list@example.com to list@example.net. This becomes involved in Mailman 3 because it affects not only Mailman core, but also mail delivery and archiving. Furthermore, the list with fqdn_listname list@example.com has the list_id list.example.com. If we change the fqdn_listname to list@example.net, the list_id should remain list.example.com per RFC 2919 Sec. 4. <https://www.rfc-editor.org/rfc/rfc2919>. We can just change the list's mail_host attribute via REST <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/listconf.html#changing-a-partial-configuration> or via a database query, but this leads to confusion. I.e., a URL like https://example.com/mailman3/lists/list.example.com/ will still work but https://example.com/mailman3/lists/list@example.com/.
To avoid this, we could also change the list_id, but we can't do that via REST as it's a read-only property, and changing the list_id says this is really a new list, not the same list with a new name.
Also, none of this addresses archiving.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Dear Mark,
thanks as always for your very thorough explanation. I guess, it is simply not practical then...
Cheers,
Johannes
Am 21.03.23 um 19:11 schrieb Mark Sapiro:
On 3/21/23 06:21, Johannes Rohr wrote:
Dear all,
on mailman2 it was possible to move a list to a different domain within the same mailman instance.
I have found no information on how the same can be accomplished on mailman3.
Is this possible at all?
In mailman 2.1, a list was identified by its name only without the domain and those names had to be globally unique. A site could be configured to support multiple virtual hosts and a list had a host_name attribute which could be changed if desired to assign the list to a different virtual host, but there couldn't be two lists with the same name even if they had different host names.
Mailman 3 is different. In order to remove the restriction that list names (without the domain) had to be globally unique, in MM 3 the domain is part of the list name. I.e., we can now have list@example.com and list@example.net as two distinct lists in the same installation.
Suppose we want to rename list@example.com to list@example.net. This becomes involved in Mailman 3 because it affects not only Mailman core, but also mail delivery and archiving. Furthermore, the list with fqdn_listname list@example.com has the list_id list.example.com. If we change the fqdn_listname to list@example.net, the list_id should remain list.example.com per RFC 2919 Sec. 4. <https://www.rfc-editor.org/rfc/rfc2919>. We can just change the list's mail_host attribute via REST <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/listconf.html#changing-a-partial-configuration> or via a database query, but this leads to confusion. I.e., a URL like https://example.com/mailman3/lists/list.example.com/ will still work but https://example.com/mailman3/lists/list@example.com/.
To avoid this, we could also change the list_id, but we can't do that via REST as it's a read-only property, and changing the list_id says this is really a new list, not the same list with a new name.
Also, none of this addresses archiving.
Teilnehmer (2)
-
Johannes Rohr -
Mark Sapiro