Plans

Setting storage, sending limits, protocols, forwarding and two-step sign-in for kinds of people at once: staff, students, shared kiosks.

An organisation thinks in kinds of people: staff get 50 GB and every protocol, students 5 GB and no POP3, shared kiosks no mail leaving the organisation. A plan is a set of settings for one kind of person. Everybody on it gets them, and changing the plan changes it for all of them at once.

The examples use the vsx shell function from the Quick start.

What a plan sets

SettingCommand lineWhat it does
Storage--storage 5GB or noneHow much each person’s mailbox may hold. See Domains and accounts.
Messages--messages 100000 or noneHow many messages a mailbox may hold.
Sending limits--sending 100/50/1000 or noneMessages per hour, recipients per message and recipients per day. See Sending and delivery.
Protocols--protocols imap,jmap,… or all, or --no-pop3 and the likeWhich ways in people on the plan may use: IMAP, POP3, submission, JMAP, CalDAV and CardDAV, ManageSieve.
Forwarding--forwarding allowed, approval, off or organisationWhether people on the plan may forward their mail outside the organisation. See external forwarding.
Two-step sign-in--two-step or --no-two-stepWhether people on the plan must use a second step.

A plan only holds these settings. It never gives anybody an administrative role.

Making plans

On the console, open Plans and choose New plan…. From the command line:

vsx admin plans add Staff --storage 50GB --protocols all --default
vsx admin plans add Students --storage 5GB --no-pop3 --two-step --forwarding off
vsx admin plans show
vsx admin plans change Students --storage 10GB
vsx admin plans remove Students

Every change first shows what it would do: how many people each plan holds before and after, and what changes for them. On the console this preview comes before Save; on the command line, add --dry-run to see it without saving.

Who is on which plan

Each person is on one plan at most, decided in this order:

  1. The plan they were put on by name. On the console, from the person’s page. From the command line, vsx admin people plan ada@example.com Students, or none to take them off. You can also give a plan when you add somebody, as a plan column in a file of people, or from your identity provider over SCIM.
  2. The first plan whose groups hold them. Give a plan one or more groups: vsx admin plans assign Students --group students@example.com. Groups nested inside count. A group that keeps its own members by a rule (see Mailing lists and groups) puts people on a plan by what the directory says about them. A group made by directory sync maps your directory’s groups to plans.
  3. The default plan, if there is one (--default).

People move between plans as soon as their groups change. A suspended person keeps their plan. When a plan is removed, the people put on it by name go back to their groups’ plan or the default.

When a person and their plan disagree

SettingWhat wins
Storage, messages, sending limitsThe person’s own setting, if they have one. Otherwise the plan’s, otherwise the organisation’s.
ProtocolsThe organisation’s access rules decide first. A plan can only leave out more.
ForwardingThe stricter of the organisation’s rule and the plan’s.
Two-step sign-inWhere the organisation requires a second step, everybody has one. Where the organisation leaves it to each person, a plan can require it. Where the organisation has turned it off, a plan cannot turn it on.

A person’s page shows each value and where it comes from, such as “50 GB, from Staff”, and so does vsx admin people plan after it puts somebody on a plan.

Who can do what

The organisation’s administrators make and change plans. A domain administrator can see them and put the people of their own domains on one; an auditor can see them. Every change is in the audit log.

Where the organisation requires approval for taking second steps away or for changing the access rules, a plan change that would ask fewer people for a second step, or open a protocol to more people, waits for a second administrator too. Its preview does not.

Over the API

RouteWhat it does
GET · PUT /api/v1/tenants/{tenant}/plansThe plans, saved whole against their version. With dryRun, what the save would change, and nothing saved.
GET · PUT /api/v1/tenants/{tenant}/accounts/{id}/planA person’s plan, how they are on it, and each value with where it comes from. A plan by id or name, or null to go back to their groups’ plan.
POST /api/v1/tenants/{tenant}/accountsTakes a plan when a person is added.

Something unclear or out of date on this page? Tell us.