I haven’t yet tried “Transfer Virtual Server”. Would this have worked here? I remember a few decades ago cPanel would throw up a maintenance page and just do all of this. I think you could do by domain or the whole server.
No control panel can change the glue records (without API cooperation at the registrar, but even registrars with APIs don’t necessarily make changing name servers trivial, I don’t know that any of our supported registrars in the domain registration plugins automate glue record changes). If OP were using any of the cloud DNS providers on both servers, a transfer should correctly handle the change, I think.
A domain transfer in Virtualmin can certainly do most of the work of transferring the configuration and domain data, but it sounds like OP didn’t have any trouble with that part of the process. But, glue records are generally outside of the control of control panels.
1 Like
There was (maybe still is) a misunderstanding about how Postfix decides who to send mail to, it’s not anything any particular piece of software ought to do differently.
Just remembering: I had a similar issue about a month ago. Disabling the vhost
on an old server (using recent webmin/virtualmin) wasn’t enough, as the entries in /etc/postfix/virtual were not disabled/removed. So, mail was delivered locally instead of, according to mx, to the new destination host.
Are these entries usually removed by virtualmin when disabling a vhost, or is this maybe a bug?
I would have guessed disabling a domain would disable its mail as well, but maybe @Jamie intended for email to keep working so the owner of the server can continue to send emails (like invoices) to the customer. I’m not sure that’s the right thing, but maybe that’s what’s happening with disabling not also disabling mail.
An IP lost a case awhile back because they disabled access but kept accepting mail. The customer sued because they claimed they were getting job offers to that address but still refused to pay past due bills to get current and demanded access to the email. Because the IP continued to accept new emails instead of bouncing them, they lost.
So yeah, if the domain is disabled it is safest to disable the mail.
I would assume the user can still login to mail if mail is not disabled?
This is kinda what I was talking about. Thread is wandering a bit. Just make sure if you WANT email off, it is off.
Well, for me it was other way round: I had sent an invoice per mail to the customer, wondering why he wouldn’t respond. Before asking the customer I
wanted to make sure he got the invoice by viewing the mail log. So it was delivered locally, while his domain was “officially” disabled on my server - and customer accounts already working on new server.
May be I should have searched earlier … 
As my mail domain was on the same server, too - the entries in the virtual map led to local delivery. Only after manually removing the entries I could send mail to his new email server.
If it is possible, when disabling a domain I would prefer
- have the possibility to disable mail reception and/or
- access to the mail accounts (since imapsync to new server may be needed) or maybe even
- having a switch which services shall be disabled.
So incoming email should be disabled, but we don’t have a way to prevent outgoing email being sent. Although if the domain owner is doing this via an authenticated SMTP connection, it should also be blocked when the domain is disabled..
No, this is about receiving on the system where the domain is disabled, not sending from it (from that domain). The OP was trying to send email from the old server (presumably from a different domain that is still active) to the new server (to a domain that was disabled on the old server).
The problem was that Postfix continued to believe it was the mail server for the disabled domain.
Which would means there’s still entries in virtual for the disabled domain. But, that conflicts with receiving mail being disabled (and OP said the mail was delivered on the old server).
Ok I see how. Yeah the only way this could happen is if the old domain is still in the virtual file, or the mydestination line in /etc/postfix/main.cf
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.