add users account with multiple email subaccounts

As an ISP, I host many company domains that provide email accounts for my customers. Each customer gets 5 email accounts as part of our service, and they can select from any of the company domains we host. They can also buy their own virtual domain, but that's another topic. It would be very useful if I could create one new email address for the primary account holder, and then that account holder would have the ability to create and manage up to X more email addresses in one or more of my company domains.

The primary account holder would not be able to see/modify other email addresses in the company domains, but they would be able to fix their wife's or kids passwords. You could have a range of options in the domain template that could be delegated to the primary account holder. We could delegate just the ability to reset passwords, or we could also allow the account holder t o create and delete sub-accounts, and a bunch of other options I haven't thought through yet.

I'm not looking for subdomains, but subgroupings of users within a single domain. The admin on my network should be able to easily see which email accounts belong to a particular customer. It can be as simple as adding an account code to each created user and allowing us to sort on it.

If the virutalmin server hosts multiple domains, the system should allow the option for the primary account holder to create his set of email accounts either in just one domain or selected domains or all domains. The admin should be able to exclude certain domains from the available list for privacy reasons.

If you got real fancy, you could extend the accounts across multiple VM servers hosting our domains. But that may be overkill.

I really could use the ability to see or manage the email accounts specific to a single customer account. Allowing the user to self manage would be a plus.

thanks... Steve



additional: would need the ability to override the "X" number of separate email addresses per account on a user by user basis. Some users get more email addresses than our standard 5 per account.

Sorry, but there is no support for this level of admin access in Virtualmin at the moment, and it would be significant effort to implement so it would be unlikely to be added any time soon. All Virtualmin permissions are at the domain level, not the mailbox level.

If you really want something like this, I would suggest writing your own PHP app that allows limited mailbox creation and talks to the Virtualmin remote API to do the actual work. See

Hmmm... it appears to be very easy. I could modify usermin/webmin/virtualmin databases myself, but any changes would be over-ridden or incompatible with future updates.

Could you at least put a "Usermin Customization" option into a usermin that we can use as an "account" identifier? Just like the "System customization" available on a virtual domain, but at the user level. We could then be responsible for and sort on that field to our hearts content and be compatible with upgrades.

Plus, custom fields could be used for lots of other things such as billing or account status functions for the user.


So by "usermin customization", do you mean like custom fields that you could set for each mailbox user?


To explain further: In virtualmin menu where we work with the list of domains, one of your sets of options is "System customization" where you allow for custom fields, custom links, etc. I haven't used custom fields yet, but the description says:

"This form can be used to create additional fields that are displayed when creating and editing virtual servers."

This implies to me that you are creating the additional field in the database structure for domains and adjusting the display routines to show it.

The same type of solution for each mailbox user would allow us to assign an account code to each user when we create their email account. If that field was then visible in full listing of users, preferably sortable, then my admins could at least see groupings of email users belonging to the same account code. We might even write a small module to do play with this. If we got real advanced, we could add a few other fields to indicate which mailbox user is the master of that account, and allow the master to see and or possible change things such as passwords for the sub-users.

While we do some minor domain hosting for others, our primary use of VMPro is to handle our email and web pages to support our customer base. We have a few thousand email accounts in 10ish domains spread across 2 servers backing each other up. If I give a customer 5 email accounts within that system, it is difficult to remember which belongs to them. We've used the real name part of the email account record as a rough account identifier, but we can't use that for the kids since their real name would then be visible to others. Also, the user can change that description so it isn't something we could count on.


We do have some perl talent here, we just haven't spent the time to master the VM/WM/UM programing environment. Lots of projects keep us busy, so we tend to your product as is.

I was assuming that you stored your basic records for user/email/ftp/etc accounts in an SQL table, hence my comment about adding a field should be easy for you, but would be fragile across upgrades for me. Where do you store the basic record for the user info - sql or do you distribute the data across the linux environment?

If I have time to push a programmer up the learning curve to write modules for VM, I'll consider adding this feature.

We don't actually use any kind of database - mailboxes are just users in /etc/passwd and other config files, which Virtualmin identifies based on their GID and home directory. So any solution would need to use some other new file or DB ..

I didn't realize you could store everything associated with the user account records scattered in /etc/passwd and other config files.

I'll look into what it will take for a simple module that will track additional user info for each user account.

I didn't realize you could store everything associated with the user account records scattered in /etc/passwd and other config files.

I'll look into what it will take for a simple module that will track additional user info for each user account.