The webmail portal at /portal
-
/portalis 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.htmlandPortal.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/portalexactly, 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'. Noteimg-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 withoutallow-scriptsand withoutallow-same-origin, under its own policy ofimg-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/portalfrom the internet, split the surfaces at a reverse proxy:/portal,/portal.jsand/api/v1/me/*public,/api/v1/sessionpublic because both pages sign in through it, and/plus everything else under/api/v1/on the internal network. 36.13IMAP clients are unaffected. The portal is another client against the same store. A flag change requires the rights
STORErequires, and every IMAP session on the folder is told. A move is IMAPMOVE: 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login