Protocols¶
INBUXA speaks JMAP, IMAP, POP3, SMTP, ManageSieve, CalDAV, CardDAV and WebDAV. Two of those are required. The rest are supported in full, and optional.
What is required¶
| Protocol | Why it cannot be switched off |
|---|---|
| SMTP | It is how mail arrives and leaves. Port 25 has to answer the internet. |
| JMAP | It is how the console and the webmail talk to the server. |
What is optional¶
| Protocol | Port | Permission |
|---|---|---|
| IMAP | 993 | imapAuthenticate |
| POP3 | 995 | pop3Authenticate |
| ManageSieve | 4190 | sieveAuthenticate |
Each of these is a permission, not just a port. That distinction is the whole point: closing a port stops connections reaching the server, while removing the permission means the server will not authenticate that protocol for those people even if something reaches it.
Switching one off¶
For one tenant¶
Add the permission to the tenant's disabled list. A tenant's disabled permissions are applied last — after its roles, after its own enabled list, and after anything an individual account was granted. So nothing inside that tenant can hand the protocol back, including an administrator of that tenant.
Other tenants are unaffected. An organization that has finished with IMAP can stop answering it without you standing up a second server for the ones that have not.
For the whole server¶
Remove the permission from the default roles, and take the listener down. Both are worth doing: the permission is what stops authentication, and removing the listener is what stops the connection arriving at all.
A tenant can never exceed the server
A tenant's ceiling can only ever narrow what the server grants. If the server does not allow a permission, no tenant setting turns it on.
Deciding¶
Turning IMAP and POP3 off is not automatically the right call. They are how every desktop and mobile mail client that is not the webmail connects, and turning them off strands those people.
Reasonable reasons to do it:
- An organization has standardized on the webmail, and IMAP is only a way in for credential stuffing.
- POP3 in particular is rarely wanted, and it downloads and deletes by default, which is a data-loss shape nobody asks for on purpose.
- ManageSieve is only needed by people editing filters from an external client; the webmail edits them over JMAP.
Reasonable reasons not to:
- Anyone using Thunderbird, Apple Mail, Outlook or a phone's built-in mail app.
- Anything automated that reads a mailbox.
What this is not¶
This does not turn off filters. Sieve scripts still run on the server as mail arrives whether or not ManageSieve is reachable — ManageSieve is only the protocol for editing them from outside the webmail.
It also does not affect CalDAV, CardDAV or WebDAV, which ride the same HTTP listener as JMAP and have no separate authentication permission of their own.