The Control Deck is the administration page hMailServer serves at /, on the same listener as the API and the portal. On Linux it is the only administration front end there is, because that build has no Control Panel and no COM. On Windows it does not replace the Control Panel and it does less. Turning it on. One setting, RestApiPort, turns on the API, the Deck and the portal together. The default is 0, which leaves all three off, so a server upgraded without touching its settings serves none of them. The listener refuses to start rather than come up without a credential or without TLS, and logs which. Four messages begin RestApi: Refusing to start. The two you will meet are an unset administrator password and a non-loopback bind with no certificate. The TLS exemption applies only to a bind address that is exactly 127.0.0.1, localhost or ::1. 36.2 Signing in. The password goes once to POST /api/v1/session and is exchanged for an hmailsession cookie that is HttpOnly and SameSite=Strict. Two ceilings apply, 30 minutes idle and 12 hours absolute, neither configurable. Any cookie-authenticated request whose method is not GET or HEAD must carry X-Requested-With: hMailServer or it answers 403; HTTP Basic and bearer keys are exempt. An API key cannot mint a session. Sessions are process-local, so a service restart ends every one. 36.3 What it does. Dashboard, Domains, Delivery queue, DANE/TLSA, Settings, Rules, Routes, Certificates, Ports and Logs. 6.3.3 added full domain editing, the account editor in full, distribution lists and aliases, an IP-ranges view, fetch-account and backup views, the scripting, cache and indexing groups, and a CI harness of 292 checks. The settings forms are worth understanding. The Deck fetches GET /api/v1/openapi.json once per session and draws each form from the schema of that group's PUT. Nothing in the page lists a settings key by name, so a key added to the API appears on its own, with its type, its permitted words, and a badge when it is read-only, write-only, required, or takes effect only on restart. The Ports view carries a Restart the services now button, which posts to /api/v1/server/reinitialize. It drops connections in progress and ends your session with everyone else's. 36.4 A few write surfaces remain API-only. Measured, not asserted. build/check-deck-parity.py counts every field the desktop Control Panel writes against the REST API and the Deck, and reports in hmailserver/docs/DeckParity.md. Of 330 properties, 240 were writable over REST and 153 reachable from a Deck view when that work started; 328 and 322 by the end of it. The two still not writable over REST are groups and their members. The six between those figures are properties the API writes and the page has no control for. Use curl for those. 36.5 still describes the 6.3.1 gaps, which were far wider. The 6.3.3 entry in the release notes is the current statement until that chapter is rewritten. Check DeckParity.md in the source tree before assuming a route does not exist.

/portal is the self-service webmail hMailServer serves out of its REST listener. A mailbox owner signs in with their own address and password and gets folders, search, compose, drafts, flags and inline images. It is not a calendar and not a groupware suite. 6.3.3 added CardDAV for the account's address book, but that is served on the web services HTTPS listener, not this one. It is compiled into the binary. There is no web root to deploy and no file to lose. At 6.3.3 the page is Portal.html and Portal.js, embedded at build time. So if the Control Deck answers and the portal does not, an absent file is not the cause. Check you are asking for /portal exactly, because the server answers that path and nothing below it, and check no proxy is rewriting it. 36.14 has the rest of the symptom table. It fetches nothing externally. No font, no image, no stylesheet, no script from a CDN. Its Content-Security-Policy is default-src 'none'; script-src 'self'; style-src 'unsafe-inline'; img-src data:; connect-src 'self'; frame-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'none'. Note img-src data:, which permits no image from any host, including this one. A sender's HTML is never merged into the page. It goes into an iframe sandboxed without allow-scripts and without allow-same-origin, under its own policy of img-src data:, so a remote tracking pixel stays in the markup and is blocked. Opening a message tells its sender nothing, and there is no setting that changes that. 36.10 explains why the obvious design cannot work. It is not an administration interface. Everything the portal does is under /api/v1/me/, and those routes answer to an account's own credentials and to nothing else. The administrator password is refused on every one of them, and so is an API key. Administration is the other page, the Control Deck at /. Both sit on one listener behind one switch, RestApiPort, so exposing one exposes the other. If mailbox owners reach /portal from the internet, split the surfaces at a reverse proxy: /portal, /portal.js and /api/v1/me/* public, /api/v1/session public because both pages sign in through it, and / plus everything else under /api/v1/ on the internal network. 36.13 IMAP clients are unaffected. The portal is another client against the same store. A flag change requires the rights STORE requires, and every IMAP session on the folder is told. A move is IMAP MOVE: a copy with a new UID, then the original expunged. Folder create, rename and delete run IMAP's checks in IMAP's order and refuse with IMAP's own sentences. The new-mail probe reads the cached per-folder collection that IMAP, POP3 and delivery already share, so polling opens no message file. Outlook, Thunderbird, Apple Mail and phones carry on unchanged, and Roundcube pointed at the IMAP port remains a reasonable choice. Full reference: 36.6 The portal: what a user gets.