After server Virtualmin restore, email aliases are invalid

SYSTEM INFORMATION
OS type and version Alma Linux 9.6
Webmin version 2.510
Virtualmin version 7.40.1
Webserver version ?
Related packages SUGGESTED

This topic is similar to After migration; mailserver issues which did not receive any responses.
I couldn’t find any other topics that covered both restoring a VM backup with invalid addresses.

Recently I had to restore a server from Virtualmin backup of a system where email was functioning correctly.

After the restore, some users started reporting that incoming mail caused a NDR that included:

user-domain.tld@hostname (expanded from name@domain.tld): unknown user: “user-domain.tld”

however the mail was delivered.

This NDR was only generated for users who had “Forward to other addresses” populated, AND for Mail aliases that forwarded to other addresses.
And for those users the Postfix Mail Alias table showed an “alias to” address of user-domain.tld
It did not happen for a simple user with a mailbox.

Virtualmin seems inconsistent in its handling of mail forwarding and aliases.

In Virtualmin I edit a user (in a domain) and go to the Email Settings section.
The user’s email is shown as user@domain.tld.
In the “Forward to other addresses” section, I add anotheruser@domain.tld (or even anotheruser@anotherdomain.tld)
and Save.

In Webmin, Servers, Postfix, Mail Aliases I see an entry:
Alias from: user@domain.tld
Alias to: \anotheruser@domain.tld and \user@domain.tld

But if I go to Save this (with no changes) I get the message:
Failed to save alias: user@domain.tld is not a valid address.

However, mail to user@domain.tld is correctly delivered to both addresses (user@domain.tld and anotheruser@domain.tld)

I’m finding this quite confusing and while I have fixed it by clicking on each affected user and then clicking Save (which rewrites the alias table),
I can’t see why the restore from backup caused the problem and how to avoid it next time.

Any help would be appreciated.

@PeterP,

What distro and version are you restoring FROM and TO?

So, I’m guessing maybe the username format changed between the old system and the new and user-domain.tld really doesn’t exist?

Is that the case? Was the old system using usernames in the form of user-domain.tld (maybe with optional user@domain.tld, as well) while the new system only has user@domain.tld?

Also, besides what Joe asked, if you try to restore another domain, and enable the “Re-generate full user names” option under the “Features and settings” panel, does it restore correctly, or does the same issue exist?

Could you please check that for us?

AlmaLinux 9.6 for both. The server crashed. I installed AlmaLinux 9.6 with Virtualmin and restored from full back the day before.
The original install was probably AL 9.0 but had been fully updated.

@Joe thanks for this. I think you’re exactly right that I started with the user-domain and enabled user@domain option soon afterwards.

@Ilia thanks for pointing out this option. I had not paid attention to it before. I will try what you suggest. It may take me a few days to setup an offline test bed that will not interfere with the production system. I’ll get back to you.

1 Like

@Jamie, I’d like to suggest again to keep “Re-generate full user names” option enabled by default.

Well the restore should work regardless of what options the user chooses, right?

@Jamie, yes, absolutely. But when the default feature isn’t working, it’s even more damaging. I will look into it more closely and try to reproduce it.

@PeterP Perhaps you could PM me a backup without including the home directory, just for one specific domain, and point out which aliases exist but shouldn’t?

@Ilia I’m away from home (and the backups) for a couple of days but I will look into sending it to you asap.

1 Like

Distro and software version are equal on both servers.

I haven’t verified this. The old system only lived with updates and on-the-fly upgrades from Debian Buster through Debian Bullseye and finally to Debian Bookworm. I’ve never upgraded via a clean install before. Always on-the-fly.

Sorry, where is this option? I dont look it in menu. It is in restore menu? I have all domains restored.

Yes, it’s on the “Restore Virtual Servers” page:

OK I look it. I restore my own domain, but no problem that i have new mail in user maildirs? There not be removed with restore operation?

Ronald, can you say that differently? I don’t think I fully understand what you mean.

I had already restored all virtual servers before reporting the problem. Postfix delivers messages to users in the Maildir directory. So the emails are delivered. Only the client programs cannot connect to Dovecot. If I now do a repeated restore from yesterday’s backup, with the settings you provided, won’t my new emails be deleted?

The suggestion Ilia made was to solve the delivery problem.

You’re talking about a different problem now, so maybe don’t do the thing that Ilia suggested for the previous problem for a new problem.

You should make a new topic about your new problem with users logging in via Dovecot to retrieve mail, as it is unrelated to aliases resolving to non-existent usernames.

Sorry, this is a mistake, I don’t know how I posted a reply to this thread. I started a new thread Problem with Dovecot restore on new install and accidentally switched here and posted here. I ask the admins to delete my posts here, they don’t belong in this thread, they are related to dovecot and the thread I started.

1 Like