Is the old hostname going away entirely? Or will it continue to be served by mail-in-a-box, and forward mail to the new hostname?
The only good way to do this would be to have a flag day… On a day that you choose, the old hostname goes dark and everybody must update their client configs to continue to use the system. (you’d send an email describing how to do this of course)
With some effort, and if you don’t mind doing wildly custom and unsupported configs to mail-in-a-box, you might be able to keep both hostnames alive so people can continue to use their old client configs. Their mail would still have to be sent and received with the new hostname.
And, if the old hostname is going away then no, it’s impossible to push new configs to clients.
(if it were possible, I’d like to know how! client config is easily my biggest source of problems with mail-in-a-box)
You can add a domain alias under the settings. All email for domain A will also be sent to all accounts using domain B. This might not be what you need but if all you’re doing is changing or adding a domain for email accounts then this should be enough.
Thanks for all the responses
This is about changing the server address users enter in their settings:
IMAP Server: hostnameA.domain.tld
SMTP Server : hostnameA.domain.tld
It’s about certificate errors mainly. Effectively both addresses point to the same server and should allow collection of mail. May try it on a test box and see what happens. Emailing everybody to change the name is a bit of a kerfuffle and I rather avoid it because it’s more of a vanity thing than critical to the operation.
A little test setup:
(obv setup hostnameA and B with same IP in DNS, which I use externally to MIAB)
install MIAB on droplet with hostname A
setup email IMAP/SMTP on device with server address hostnameA
send/receive mail to check it all works
change droplet hostname and reboot (make sure it sticks)
run setup script again and change hostname A to B
leave settings on device as they were (hostnameA)
Note that the original address (test@hostnameA) remains on the system and both the new and old have valid SSL certs set-up. The new hostname (B) needs a certificate installing manually though, I removed the previous server certificate first (ssl_certificate.pem). I provisioned a new one by running the setup script again although I probably should have been less lazy and just looked up how to provision the cert again from the command line.
OK, so what happens is that because of device connecting to hostnameA, but the server responding with hostnameB, the user gets a certificate warning - duh.
In summary, there is no way around telling users they need to update the server addresses :’(
Which is what @bronson said in the first place, so I should’ve really listened