The webmail portal at /portal

[Progressiverobot]

/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.