After adding a new user, the user’s email account will automatically be active in the mail1 module. How can it be set so that it is inactive by default and I can later enable the email account for whomever I want. We prohibit e-mail access for 99% of smb accounts, we allow only a few users to use e-mail.
You can deactivate the mailbox directly in the Mail Server app under the ‘Mailboxes’ tab by clicking on the three vertical dots to the far right of the relevant user and selecting ‘Deactivate’.
I would like to activate each account individually once email access has been enabled for it, rather than deactivating all accounts after they are created. Currently, we often forget to deactivate them.
That does work, though, using the method I described.
Or do you want the newly created account to be deactivated automatically? I can’t say whether or how that would work.
Mail doesn’t support this today: new users always get an active mailbox.
We have an (untested) idea for a custom configuration that keeps mail access off by default and allows only the accounts on a list you keep. It may not work at all. If it does, these limitations would apply:
You’d edit the list of enabled accounts by hand in a text file on the server.
The UI’s mailbox enable/disable switch must not be used. It could even turn mail access back on for all users.
If the user domain is reconfigured, the configuration has to be updated by hand.
It’s unsupported, and there are no plans to make it a feature.
Would that be acceptable for you?
It would also help to know roughly how many users in total, how many mailboxes you’d enable and how often that list changes.
we have around 100 users, and new ones are added from time to time. We use dedicated user accounts for email—such as mail_it, mail_hr, mail_special, mail_orders, etc.—with corresponding aliases like it@ and hr@. It would be ideal if the mail module allowed us to configure whether a new user’s email account starts as active or inactive. Currently, they are active by default, meaning we have to manually deactivate them (a step that is often overlooked).
From your description, the mail accounts (mail_it, mail_hr, mail_orders…) are already separate from the regular company accounts, with their own passwords. If so, a separate user domain may be simpler than an “inactive by default” option.
There’s also a design reason. The Mail app expects most users to have mail enabled and only a few exceptions disabled. Each disabled account is added to the LDAP query filter, so disabling ~100 accounts would produce a very large filter. That’s the opposite of the case the app is built for.
NS8 supports multiple user domains in the same cluster, so you could set it up like this:
LDAP1: the existing domain with all company users (~100 accounts), used by file shares and the other apps.
LDAP2: a new internal OpenLDAP domain with only the mail-enabled accounts.
Mail app bound to LDAP2: only users in that domain get a mailbox.
New users created in LDAP1 never get a mailbox, so there’s no deactivation step to forget. Adding a mail user becomes a deliberate action: you create the account in LDAP2. The it@ and hr@ aliases keep working as now, pointing to the LDAP2 accounts.
Keep in mind that mailboxes are tied to user names. To switch the Mail app from LDAP1 to LDAP2 and keep the existing mailboxes, create the LDAP2 accounts with the same names they have in LDAP1 (mail_it, mail_hr, mail_orders…).
Out of the 100 accounts, about 20 are group or fictitious accounts—such as one dedicated to a supplier—while the remaining 80 are AD user accounts with actual login capabilities. Email access is enabled for approximately 15 of them. If we were to use a different LDAP system, we wouldn’t be able to keep the AD passwords synchronized with IMAP/SOGo usage. Never mind; if it’s difficult to resolve, we’ll just stick with the practice of continuously deactivating them.