Mail alias is not deleted with mail user

OS type and version Debian 10
Webmin version 2.105
Virtualmin version 7.9.0
Related packages SUGGESTED

Hello, I am using Virtualmin Pro and I am experiencing the following issue:

I created an email user, “”, and added it as a mail forwarding destination for another email user. However, when I delete the email user “example2,” the mail forwarding setting is successfully removed, but the email alias associated with it still remains in the /etc/aliases file. As a result, emails sent to the deleted email user’s address continue to bounce.

Additional information:

  1. When the user is deleted and add them as a mail forwarding destination, the mail forwarding setting performs a user check and removes the user from both the forwarding setting and the /etc/aliases file. However, this check seems to be not performing after a user deletion and I have to manually remove it from “/etc/aliases”
  2. Additionally to mention, that the email user “example2” in question belongs to an existing domain within the virtual server. Ideally, Virtualmin should perform the necessary checks and validations for such cases.

Is this a bug or unintended issue, a feature which must be reconfigured or a new feature added? Is there any way that could be automated?

Hello @Ilia and @Joe ,

I was wondering if I could seek your expert opinion on this matter? Your insights would be greatly appreciated. Thank you!

Please don’t ping us. We read/respond to what we can when we can.

1 Like

I tested with a user with a forward, deleting the user also removed the forward in the /etc/aliases

test@mydomain to forward to alias line looks like this, is that what created on your system?

deleting the users (or unticking the forward) deletes thats line.

Let me show you my steps:

  1. First I create “” user.
  2. Then i create “” like this with an address for forwarding “”:
  3. Check what i see in “/etc/aliases” is:
cat /etc/aliases | grep example \example2\,\
  1. Now when i delete user “
  2. And check again he is still in “/etc/aliases”
cat /etc/aliases | grep example && date \example2\,\
Thu  8 Feb 09:31:35 EET 2024
  1. I also still can see it in the panel:

Excuse me please, I just want your expert opinion on this. I will kindly wait, thank you.

Yeah I don’t get that issue. I use Rocky 9.
Maybe there a issue with virtualmin and Debian 10.

1 Like

FYI, I just fired up a Debian 10 OS and installed Virtualmin, restored one of my test domains and I can replicate your issue.

So look like a bug with that OS.

1 Like

Thank you for the information, I appreciate it!

@m.stoyanov I understand now what you mean. The topic’s title is a bit misleading.

@Jamie, I think we didn’t try to implement yet this kind of feature, i.e. to delete configured forward in a user when targeted user is deleted?

For example, if a user and are created and then will forward mail to but user is later deleted, then the record that pointed to in /etc/aliases would still be present in alice\ line.


I suppose we could do that in theory, but it seems risky because the admin might want to re-create the user immediately afterwards but now the forward would be gone.

Maybe just a popup alert saying that a forward exists and that forward should be deleted before the user can be deleted?

there are a couple of problems automating the deletion of email forwarders

  • not all forwarders send email to domains controlled by the local virtualmin server, i.e. exgternal domains.
  • if you use testing the remote email account might be off temporarily for maintenance etc…
  • the handling of forwarders should be the responsibility of the account owner or admin
  • on a real edge scenario, this would break GDPR because it would be using information from one account without consent, to alter the behaviour of another account.

As we can easily check if forwarded address is setup for a local user, deleting it is more reasonable, rather than expecting that deleted user would be recreated.

As we can easily check if forwarded address is setup for a local user, deleting it is more reasonable, rather than expecting that deleted user would be recreated.

I suppose that would be a safe thing to do. Send me a PR!

1 Like

I will in a bit!

Is this scheduled to be imported in the next update?