Sign-in security: lockouts, history, sessions and alerts
Every password check, in webmail and in mail apps (IMAP, SMTP sending, ManageSieve and JMAP), goes through the same guard. It records the attempt, slows down addresses that guess, locks accounts that get too many wrong passwords, and tells users what happened when they want to know.
Lockouts
- Each address is slowed down after 10 failures in 15 minutes, on each server, so one machine cannot guess quickly.
- On top of that, an account is locked after 10 wrong passwords within 15 minutes (from anywhere), for 15 minutes. A wrong two-step code counts as a wrong password.
- A locked account cannot sign in even with the right password. Mail apps and webmail get the same "too many failed sign-ins, try again later" answer as a slowed-down address, so a lockout does not tell a stranger that an address exists.
- An administrator can lift a lock early: Unlock next to the user on the tenant's page (or the team's page in the domain admin panel), or
corpsuite mailbox unlock USER.
Someone who knows an address can lock it on purpose by typing wrong passwords. Keep the lock short (minutes, not hours) so that costs the user little, and turn on two-step sign-in for accounts that matter.
The operator changes the numbers under Settings → Sign-in security in the admin panel, or corpsuite security set lockoutThreshold:=8 lockoutWindowMinutes:=15 lockoutMinutes:=30. A threshold of 0 turns lockouts off (the per-address slowdown stays).
Sign-in history
Every attempt is kept with its time, service, address, browser or app (where the service says), and why it failed: a wrong password or code, a locked or suspended account, or a service not in the plan. Mail apps that stay signed in are noted once every half hour per address, so the list stays readable.
- Users see their own under Settings → Security in webmail.
- Administrators see a user's under Sign-ins on the tenant's page, and with
corpsuite mailbox signins USER. - History is kept for 90 days by default; change Keep sign-in history for (
historyDays). Older entries are deleted every hour.
Each account also shows its last sign-in (time and address) and the address it signed up from, for self-service signups and team join pages.
Sessions
Webmail sessions keep the address and browser they started from. Users see where they are signed in under Settings → Security → Where you are signed in, and sign out any other browser, or all of them. Administrators see a user's sessions under Sign-ins and can Sign out everywhere (corpsuite mailbox sessions end USER). Changing the password signs out every session and mail app too.
How long sessions last
Sessions are kept in the database, so restarting or upgrading the server never signs anyone out. While the server is restarting, open pages say they cannot reach it and try again, and carry on once it answers; they never show the sign-in page because of it.
A session ends when it reaches its length after signing in, or when it has gone unused for its idle limit, whichever comes first. Staff set both for each kind of session in the Zappocity panel (Settings → Sign-in security, the Sessions card), in minutes:
| Session | Length | Idle limit |
|---|---|---|
| Staff and team admin panels | 720 (12 hours) | 60 (1 hour) |
| Webmail | 10080 (7 days) | 1440 (1 day) |
| Zappocity account and single sign-on | 43200 (30 days) | 10080 (7 days) |
Each is 5 minutes to a year (525600), and an idle limit cannot be longer than its session. A shorter limit ends sessions already open that are past it, within 30 seconds; a longer one applies from the next sign-in, because the browser keeps the cookie only as long as the session was meant to last when it began. From the command line: corpsuite security set adminIdleMinutes:=240 webmailIdleMinutes:=4320.
Security alerts
Users are emailed, at their address and their recovery address:
- when their account is locked, or after three wrong passwords in a row;
- when it is signed in to from an address it was not used from before.
They turn each alert on or off under Settings → Security → Security alerts. The operator chooses whether alerts are on for people who have not chosen (Email users about new sign-ins and wrong passwords unless they turn it off, on by default).
Verification
An account shows whether it is verified, since when, and how:
| Method | When |
|---|---|
email | The user confirmed a recovery address by its link, or proved an address elsewhere at signup (Signup verification). |
sms | They proved a mobile number with a code at signup. |
invite | They signed up with an invitation link (the operator's, a user's or a team's). |
team | Their team's admin added them in the domain admin panel. |
manual | The operator marked them verified. |
The operator marks an account verified by hand with Verify on the tenant's page (with a note on how it was checked), and takes that away with Unverify; corpsuite mailbox verify USER verified:=true note="Called them".
Captchas on webmail sign-in, signup and reset requests are described in Abuse protection.
Approving signups
With New signups wait for my approval on (Settings → Signup, or corpsuite settings set signupApproval:=true), every self-service signup is created but waits: it cannot sign in or receive mail. The signup page tells the person so. Invitation links are not held, since the invitation is the approval.
Waiting tenants show on the overview and have Approve and Reject on their page (corpsuite tenant approve TENANT, tenant reject TENANT). An approved free account works at once; a paid one still waits for payment. A rejected one is suspended.