Webmail domains
Settings > Webmail domains gives each webmail feature a hostname of its own - mail.example.com, meet.example.com, chat.example.com, files.example.com, docs.example.com, book.example.com, ai.example.com - instead of the panel's address and port.
Without it, everything the webmail carries answers on one URL: https://control.example.com:2096/. That is fine for the mailbox, whose reader signed in there. It is not fine for the links the webmail asks other people to open - a meeting invitation, a booking page, a share link forwarded outside the company. A port in a URL is something the recipient has to be told about, some corporate proxies refuse it, and a hostname that says "control panel" reads as suspicious.
With a domain configured, the same invitation carries https://meet.example.com/meet/join/ab12cd and needs no explaining.
What actually changes​
| What listens | Nothing new. Each hostname is an ordinary vhost on the front-end's existing 80 and 443, proxying to the webmail on 127.0.0.1:8892. |
| Firewall | No change. No per-feature port is exposed; 80 and 443 are already open for the hosted websites. |
| HTTP | Redirected to HTTPS (301), except the ACME challenge path, which has to stay reachable for renewals. |
| TLS | The name's own certificate, issued through the stack's ACME client. Until it can be issued, the panel's certificate is served so the page is still encrypted - browsers warn until then. |
| Application | One deployment: one backend, one database, one build. The hostname decides the landing page and the links, nothing else. |
| Sessions | A session cookie belongs to one hostname, so signing in happens once per name. |
Before you add one​
- Point the subdomain's DNS A (or AAAA) record at this server. Until the name resolves here, no certificate authority can validate it. The domain is still added and served - under the panel's certificate - and the certificate is ordered automatically on the next AutoSSL sweep once the record lands.
- No firewall port is needed. Traffic uses the existing 80 and 443.
Adding a domain​
In the panel: Settings > Webmail domains, type the hostname next to the feature and Save. The message you get back is the CLI's own - "certificate issued", "waiting for DNS to point here", "the front-end rejected it" - not a generic "saved".
From the command line:
hitechcloudcli native-webmail domain list
hitechcloudcli native-webmail domain add meet meet.example.com
hitechcloudcli native-webmail domain remove meet
Adding one does all of this in order: records the name, writes /etc/hitechcloud/native/frontend/conf.d/<hostname>.conf, reloads the front-end, orders the certificate, re-renders the vhost with it, updates the webmail's environment and restarts the webmail.
The features​
| Feature | What the hostname opens | Links it owns |
|---|---|---|
webmail | The mailbox | - |
meet | Meetings | /meet/join/<code> |
chat | Team chat | /chat/guest/<token> |
files | Files | /s/<token> |
docs | Documents | /docs/s/<token> |
booking | Booking pages | /book/<slug>, /book/manage/<token> |
ai | The assistant | - |
Every route still works on every hostname - the names are a front door, not a partition. What a feature's own name changes is the first screen when somebody opens it, and the base URL of the links that feature generates.
Where it is stored​
| Path | What |
|---|---|
/etc/hitechcloud/native/webmail/domains.conf | One FEATURE_DOMAIN=hostname line per configured feature. The source of truth. |
/etc/hitechcloud/native/frontend/conf.d/<hostname>.conf | The generated vhost. Regenerated by native-webmail configure; hand edits are lost. |
/etc/hitechcloud/native/ssl/<hostname>/ | The certificate and key. |
/etc/hitechcloud/native/webmail/webmail.env | FEATURE_HOSTS (which host is which feature) and APP_EXTRA_ORIGINS (the same list as origins, so WebSockets from those pages are accepted). Both are derived from domains.conf - edit the conf, not the env. |
What a webmail domain does not change​
Giving the mailbox itself a name (mail.example.com) changes where customers open it and the base of the links the webmail generates for that feature. It does not move APP_URL in webmail.env, which is still the panel's own address (https://<panel host>:2096) - and that is what single sign-on registered as its redirect URI, and what password-reset and invitation emails are built from. Both addresses keep working; signing in through the panel's OpenID Connect provider continues to come back to the panel address.
Renewal​
Service domains are renewed by the same hitechcloud-autossl timer that renews the hosted sites, and a renewal re-renders their vhosts so the new certificate is actually served. Check one at any time:
hitechcloudcli native-ssl status meet.example.com
hitechcloudcli native-webmail domain list
Removing a domain​
Clear on the page, or hitechcloudcli native-webmail domain remove <feature>. The vhost goes away and the feature returns to the webmail's own address. The certificate is left on disk; remove it with hitechcloudcli native-ssl remove <hostname> if the name is gone for good.
Troubleshooting​
| Symptom | Cause |
|---|---|
| Browser warns about the certificate | The name did not resolve here when it was added, so the panel's certificate is being served. Fix the DNS record and run hitechcloudcli native-ssl issue <hostname> --no-wildcard. |
... is a website hosted on this server | The hostname is already a hosted domain. Its vhost belongs to that site; choose a name that is not hosted. |
... is already the <feature> domain | Two features cannot share one name. Remove it from the other feature first. |
| The page loads but new mail, chat or a meeting never connects | The WebSocket origin. APP_EXTRA_ORIGINS in webmail.env should list the domain; re-run the add command, which rewrites it and restarts the webmail. |
| The domain shows the mailbox instead of its feature | FEATURE_HOSTS in webmail.env is stale, or the webmail was not restarted: hitechcloudcli native-webmail domain add <feature> <hostname> again. |