Thomas Krichel writes:
Stephen J. Turnbull writes
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.
I'm saying that when you come to this list, you will get better service if you have a reasonably fresh build from PyPI or source in a venv.
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.
It's based on conversations with the DMARC working group participants, including the head of email security at Yahoo at the time. In any case, it's well-known that spam-fighters use machine learning models that assess a wide variety of attributes of each message. I assume that claimed, and especially validated, sender identity would be among them.
(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.
Not true. You can't fake valid DKIM signatures, you can't fake DMARC From alignment, and you can't fake valid ARC seals. If the List-ID is signed by either DKIM or attested to by ARC, you can't fake that, either. On the other hand, a useful IP is often not available, or is lumped in with a whole netblock (especially in the case of IPv6).
In any case, if you're DKIM-signing the RFC 2369 and RFC 2919 headers with the key of the list domain, recipients can generally trust that because normally the list host's signature arrives valid.
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.
I don't know what the mail_host is.
It's the SQL database name of the field that contains the domain of the list. You "su mailman", invoke the command line utility such as psql or mysql which probably will connect to the 'mailman' database, and issue a simple SQL command. I think you need to be a little more careful, with something like
UPDATE mailinglist SET mail_host = 'NEW_dom' WHERE mail_host = 'OLD_dom';but that will effectively change the domain of all the mailing lists on 'OLD_dom' in the 'mailinglist' table. I guess you probably want to change the web host, too, so future messages would have the correct archive URLs in the message header and mailing list footer.
- 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.
Which is why I would be careful about making the list's own archive diverge from the content in their mailboxes, which their MUAs will be using to compose the headers in their posts to the list.
I'm willing to bet that some of your members will compose email by hitting reply-to-list to a message from OLD_dom, and aware of the change will fix up the To address to @NEW_dom by hand. But (unless they're real mail nerds) they will not update the References and Reply-To headers, breaking those threads in your archives because HyperKitty won't recognize the IDs in those posts' References.
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.
Thanks! It's helpful to know what people are trying to do.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan