The webmail portal at /portal

/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 has contacts too, and since 6.3.4 calendars and tasks and the organisation's directory. CardDAV (added in 6.3.3) and CalDAV (6.3.4), for other clients, are 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.4 the page is Portal.html and Portal.js, with its manifest, service worker, language catalogues and OpenPGP and S/MIME modules, all 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 the page at that path alone (what it serves below /portal/ since 6.3.4 are other pages: single sign-on, password reset, password-protected messages), 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 'self' data: blob:; connect-src 'self'; frame-src 'self' blob:; manifest-src 'self'; worker-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'none'. Note img-src 'self' data: blob:, which permits no image from any other host; 'self' is there for images the server answers from its own routes, such as a colleague's directory photo. 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 unless the reader chooses otherwise: showing remote content, for that message or always for that sender, serves the message under img-src data: https: http:, and the pixel then loads. 36.10 explains why the obvious design cannot work.

It is not an administration interface. Everything the portal does with a mailbox 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: the webmail public, /api/v1/session public because both pages sign in through it, and / plus the administration routes under /api/v1/ on the internal network. At 6.3.4 the webmail is more than /portal, /portal.js and /api/v1/me/*: it loads /portal-*.js, /portal.webmanifest, /portal-sw.js and /portal-lang/, and, for the features you switch on, people who are not signed in reach pages and routes such as /portal/*, /files/, /confidential/, /lists/, /held/, /recovery/verify, /api/v1/password-reset, /api/v1/passkeys/challenge and /api/v1/protected/. Check the proxy's list against what you use. 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.