Administrators

SmarterMail allows a single installation to have multiple system administrator logins, each with their own unique login and password. Once the page loads, you'll see a list of the administrators that are set up for the SmarterMail installation. System administrator accounts are the most powerful accounts in a SmarterMail installation — they can see and change settings for every domain and every user on the server — so this page is also where you control who has that level of access, how strong their passwords must be, and where they're allowed to log in from.

Administrators

Initially, there will be a single "Primary" administrator showing. As new administrative accounts are created, they will also be displayed. By default, the following columns are displayed:

Account - The login name associated with the account.
Name - The friendly name associated with the account.
Type - The account type: Primary Administrator or Administrator.
Manage Admins - If the administrative user has been granted permissions to create/manage other administrative accounts, a checkbox will appear next to their name. This reflects the Manage secondary administrators permission described below.
IP Restrictions - If the administrative user is restricted to connecting from a specific IP address, or an IP range, a checkbox will appear next to their name.
Created - The creation date/time of the administrative user.
Enabled - Whether the specific user is enabled or disabled. No checkmark means disabled.
Last Login - The date/time the specific user last logged into.

Every system administrator — whether or not they hold the Manage secondary administrators permission — can see this full list of administrator accounts. That permission doesn't control visibility of the list; it controls whether the administrator can edit, create, or delete anyone else's account, and whether they can grant administrative permissions to others. An administrator without the permission can still open their own account from this list and change their own settings (display name, password, language, and so on), but the interface for other accounts is read-only for them.

Note: Regardless of permissions, no secondary administrator can ever modify the Primary Administrator's account — not their password, their status, or any other setting. Only the account that actually holds Primary Administrator status can change its own settings. This is enforced even for secondary administrators who otherwise have full Manage secondary administrators rights.

Example: A mid-size hosting company wants three members of its operations team to be able to manage customer domains and troubleshoot mail flow, but the company only wants its lead sysadmin creating or deleting admin accounts. The lead sysadmin (the Primary Administrator) creates three secondary administrator logins for the ops team, leaves Manage secondary administrators unchecked for all three, and enables Restrict login access by IP so each of them can only log in from the office's public IP address. The three ops accounts can do their day-to-day work — managing domains, resetting user passwords, reviewing logs — but none of them can create a fourth admin account, change each other's passwords, or touch the Primary Administrator's settings.

Password Requirements

SmarterTools gives primary system administrators the ability to set password requirements for any other system administrator that's created. This can help ensure that administrators create strong passwords since their accounts hold the keys to the entire SmarterMail system.

Requirements

Minimum Password Length - Enter the minimum number of characters the password must have.
At least one number - Select this option to force users to include a number in the password.
At least one capital letter - Select this option to force users to include a capital letter in the password.
At least one lowercase letter - Select this option to force users to include a lowercase letter in the password.
At least one symbol - Select this option to force users to include a symbol in the password.
May not match username - Select this option to ensure that the username and password do not match.

Options

Prevent common passwords - Select this option to prevent users from configuring passwords that are included in the list of commonly used, insecure passwords.
Prevent previous passwords reuse - Select this option to prevent an administrator from reusing a password they've used before. This rule is off by default, meaning that unless you enable it, administrators are free to reuse old passwords.
- Previous Passwords to Block - This number controls how much of an administrator's password history is checked when Prevent previous passwords reuse is enabled.
  - A value of 1 only blocks re-using the password the account currently has — in other words, the new password just has to be different from the current one.
  - A value greater than 1 (for example, 5) blocks the current password plus that many minus one of the most recently used passwords. A value of 5 means the current password and the four passwords used before it are all off-limits, so an administrator would need to cycle through five unique passwords before an old one becomes eligible for reuse again.
  - The default value is 0, which is the strictest setting of all: it checks the administrator's entire stored password history, not just the most recent few. Don't read 0 as "no restriction" — it's the opposite. If you actually want no reuse restriction at all, leave Prevent previous passwords reuse unchecked instead of setting this value to 0.
Skip enforcement for existing passwords - By default, SmarterMail retroactively enforces password requirement changes: the next time an existing administrator logs in to the web interface (Webmail) and their current password doesn't satisfy the requirements configured above, they're routed through a forced password-reset flow before they can continue. Enabling Skip enforcement for existing passwords turns this retroactive check off, so administrators who already have a password that predates the new requirements are permanently left alone until they voluntarily change their password — only newly created accounts or passwords set going forward are checked against the current rules. Either way, this setting has no effect on the Primary Administrator or on cluster/HA administrator accounts, which are never subject to this retroactive check.
Enable password retrieval - Select this option to allow administrators to reset their password if they forget it, using the Reset Password link on the login page.
Note: In order for an administrator to use password retrieval, they must have a Recovery Address (for example, admin@example.com) configured in their own account settings. Without one, there's no address SmarterMail can send the reset link to, and the administrator will need someone with the Manage secondary administrators permission — or the Primary Administrator — to reset the password for them instead.

Adding New Administrators

To create a new administrator, click the New button.

Note: Only the primary administrator and secondary administrators with the Manage secondary administrators permission can create new administrators or modify existing ones.

When adding or editing an administrator, the following settings will be available:

Options

Username - The identifier used to log in to SmarterMail.
New Password - The password used to log in to SmarterMail.
Confirm Password - Re-type the password used to log in to SmarterMail.
Display Name - A friendly name for the administrator. For example, "Dan Henderson".
Status - Enabled or Disabled. Disabling an account immediately blocks that administrator from logging in, without deleting the account or its configuration. This is a quick way to lock out an administrator whose access needs to be suspended — for example, someone who's left the company — without losing an audit trail of who they were.
Note: The Primary Administrator account can never be set to Disabled. This is a built-in protection so that a SmarterMail installation can never be left with no way to log in.
Language - The language and locale the administrator's account uses. It's worth taking a moment with this setting, because it does more than change what's displayed in the webmail interface. The language selected here is the basis for every resource SmarterMail returns for that administrator's account — interface labels and folder names in webmail, yes, but also the content SmarterMail hands back to email clients connecting over IMAP, EWS, or ActiveSync (Outlook, eM Client, iOS Mail, and similar), calendar and appointment data, contact groups, and log file entries. Because of that reach, choose the language that actually matches the administrator's own working language before the account is used day-to-day; changing it later is possible, but retroactively re-localizing content that clients have already synced can be messy. Example: if an administrator based in Germany is set to English instead of German, they won't just see an English admin panel — folder names, calendar text, and other synced content their mail clients pull from the server will come through in English as well, even though their own client's OS is set to German.
Allow impersonation - Select this option to allow the administrator to impersonate a domain or user. Impersonating opens a new browser session logged in as that domain or user, with no password required and no change made to the account's actual password. See the Impersonate User page for full details on how impersonation works and what it's used for. Only the Primary Administrator has this permission by default; a secondary administrator can only grant Allow impersonation to another secondary administrator if their own account already has that permission enabled.
Allow show passwords while impersonating - User passwords are hidden by default, even from administrators. Select this option to allow an administrator who also has impersonation permissions to view the plain-text passwords associated with users, and to retrieve those passwords via the API. Because this is layered on top of impersonation, an administrator can only be granted this option if they already have Allow impersonation, and it can only be granted by someone who already holds this same permission themselves.
Note: The Primary Administrator can view and retrieve user passwords and app passwords by default, without needing this option explicitly enabled. When a domain is configured to use Active Directory authentication, passwords are never displayed to any administrator, primary or otherwise, since SmarterMail doesn't store them.
Restrict login access by IP - Select this option to only allow the administrator to log in, and to make system-administrator API calls, from certain IP addresses. Then enter the authorized address(es) on the IP Restrictions card. See the IP Restrictions section below for details on the address formats supported and exactly what happens when a login or API call comes from a disallowed address.
Force two-factor authentication - Select this option to require this specific administrator to use two-factor authentication when logging in. This is a per-administrator setting — there isn't a separate, server-wide switch that forces two-factor authentication for every administrator at once, so if you want every secondary administrator to use it, this box needs to be checked on each of their accounts individually. The Primary Administrator's account is exempt from being forced into two-factor authentication through this option; the Primary Administrator can still choose to enable two-factor authentication voluntarily on their own account, they just can't have it mandated for them by another administrator.

Two-Factor Authentication

Two-factor authentication is a great way to further secure the logins for system administrators. When enabled for an account, that administrator chooses between two methods: a one-time code emailed to the address on file, or a time-based code (TOTP) generated by an authenticator app, such as Google Authenticator or Microsoft Authenticator. Whichever method is selected, the administrator will need to supply that second factor every time they log in, in addition to their username and password.

If an administrator loses access to their authenticator app or their email account, recovery isn't handled through backup codes. Instead, it relies on the Recovery Address configured on that administrator's account (the same field used for password retrieval, described above) — SmarterMail can send a recovery message to that address to help the administrator regain access. Because of this, it's worth confirming every administrator has a valid, reachable recovery address configured before they turn on two-factor authentication, not after they're already locked out.

IP Restrictions

If an administrator has Restrict login access by IP enabled for their account, this is where you add the IP addresses that are allowed access to the SmarterMail server for that administrator. SmarterMail accepts entries in three formats:

A single IP address, such as 203.0.113.10.
A hyphenated IP range, such as 203.0.113.1-203.0.113.50.
CIDR notation, such as 203.0.113.0/24.

Wildcard entries aren't supported, so a range or CIDR block has to be used to cover more than one address. Loopback connections (127.0.0.1 or ::1) are always allowed through regardless of what's configured, since those represent the server itself.

When a login attempt or an API call for a system-administrator scope arrives from an address that isn't on the allowed list, SmarterMail rejects it outright with an "IP Restriction Violated" error — the request never reaches the point of checking credentials, let alone processing anything. This applies equally to the Primary Administrator's account: Primary Administrator status does not exempt an account from its own IP restrictions, so if you enable this option on the primary account, make sure the address list is correct, or you can lock yourself out of the installation.

It's also worth noting that system-administrator API calls are checked against two independent layers: the general IP whitelist/blacklist that applies to API access broadly, and this administrator-specific IP Restrictions list. Both checks happen after the API call authenticates but before it's allowed to execute, and either one failing is enough to reject the call. Neither layer is required, but using them together is strongly recommended for locking down API access to only the systems that legitimately need it.

Example: Using the scenario above, the hosting company's three ops-team accounts could each be restricted to the office's public IP range (say, 203.0.113.0/28), so that even if one of those accounts' credentials were ever compromised, they couldn't be used to log in or make API calls from outside the office network.

Change Password

Administrators can reset their own password at any time by logging into the web interface. In addition, the primary system administrator and administrators with the Manage secondary administrators permission can change another administrator's password. To modify an administrator's password, select the administrator and click the Change Password button, then enter and confirm the new password.

Note: As with every other setting on this page, secondary administrators cannot change the Primary Administrator's password, no matter what permissions their own account holds. Only the account holding Primary Administrator status can change its own password.

Administrators who cannot remember their own password can find instructions for resetting their username and password in the SmarterTools Knowledge Base.