Kolab requires at least one public IP to function.
On a single node deployment one IP is enough. For a cluster-setup at least 3 internal ip's are required, that are claimed by services via metallb:
* Postfix requires a dedicated IP for port 25 email receiving
* Coturn requires a dedicated IP
* Managesieve requires a dedicated IP because it is not proxied via the nginx proxy.
* The nginx proxy claims one IP for all other services, forwarding the client ip as necessary.
The dedicated IP requirement stems from how services are exposed via metallb, and the requirement to see client-ips.
It would in principle be possible to consolidate all services on a single IP by routing everything over a proxy, but this requires making all components compatible with the proxy protocol to forward the client ip (postfix via postscreen).
Metallb currently requires dedicated ip's because the service *must* be on the same node as the destination pod for the client-ip to be accurate.
### Client-IP
Various components require that the client-ip is available for them to function properly:
* Postfix requires the client IP on port 25, for various checks
* Coturn requires the client IP for RDP traffic routing.
* The NGINX proxy requires the client IP for imap/submission for rate-limiting and access control checks.
For http based traffic the client ip may also be required (e.g. for dav/activesync 2fa), but over http the X-Forwarded-For header may be used (set by ingress by default).
+ * `/Microsoft-Server-ActiveSync`: Activesync via NGINX Proxy to roundcube container
+ * `/dav`: Dav via NGINX Proxy to imap container
+ * `/webmail`: Roundcube via NGINX Proxy to roundcube container
+ * `/chwala`: Chwala file api via NGINX Proxy to roundcube container
+ * `/browser, /hosting, /cool`: Collabora http endpoints via NGINX Proxy to collabora container
+ * `/meetmedia`: Kolab Meet http endpoint
+ * `/.well-known`: Various .well-known endpoints for autoconfig
+ * `/mail/config-v1.1.xml`: Mail autoconfig
+ * `/prometheus`: Prometheus
+ * `/select`: Victorialogs API
+ * `/alertmanager`: Alertmanager UI
+* Port 143:993 (via metallb, proxy ip):
* IMAP via NGINX Proxy
-* 465/587(via metallb, proxy ip):
+* Port 465/587(via metallb, proxy ip):
* Submission for clients
-* 25 (via metallb, smtp ip):
+* Port 25 (via metallb, smtp ip):
* SMTP for mail delivery
-* 3478 (via metallb, turn ip)
+* Port 3478 (via metallb, turn ip)
* Coturn for Webrtc
## DNS
To successfully send and receive mail, various dns related aspects must be configured properly.
### PTR records
A PTR record must be available for all ip's that appear as source addresses when sending emails, so that a dns reverse lookup resolves to a domain that also points to the same IP via A record.
(postfix reject_unknown_client_hostname).
### MTA-STS
MTA-STS applies to inbound email from other parties. It requests from a compliant mailexchanger to only deliver email over tls,
and only to the ip's listed in the mta-sts policy
* Before submitting mail the MTA-STS policy on https://mta_sts.$domain/.well-known/mta-sts.txt will be looked up, which looks like this:
```
version: STSv1
mode: enforce
mx: mx01.kolabnow.com
max_age: 604800
```
* It will also lookup _mta-sts.$domain with a policy id that should change when the policy changes.
* Email will only be delivered to the servers listed in the policy file.
The mta-sts. CNAME record is only required if we don't provide the policy directly from that subdomain.
### DKIM
DKIM is applied to individual emails, and ensures the header information of each mail has not been tampered with.
Each mail is signed with a private key, the recipient verifies the signature after looking up the public key on the senders domain (d= in signature).
Amavis implements dkim signing and verification.
The published dkim key must match the selector used in the signature (s=dkim1), which is used to select the correct dkim public key in dns (on the domain in the d= in the signature).
By using different selectors, multiple dkim signatures are possible, e.g. for key rotation.
+Roundcube is the webmail application that Kolab uses and actively develops.
+In addition to webmail it provides comprehensive groupware functionality, through a variety of plugins.
+
+``` mermaid
+graph TD
+ HTTPD --> Roundcube
+ Roundcube --> |Mail over IMAP|IMAP[Cyrus IMAP]
+ Roundcube --> |Contacts over CardDAV|IMAP[Cyrus IMAP]
+ Roundcube --> |Calendars over CalDAV|IMAP[Cyrus IMAP]
+ Roundcube --> |Send emails|Postfix
+ Roundcube --> |Syncronization state|Mariadb
+ Roundcube --> |Caching|Redis
+```
+
+## Syncroton
+
+Syncroton is an implementation of the ActiveSync protocol, based on the Roundcube framework. It allows devices to synchronize Email, Tasks, Calendars and Contacts stored in Cyrus-IMAP via
+
+``` mermaid
+graph TD
+ HTTPD --> Syncroton
+ Syncroton --> |Mail over IMAP|IMAP[Cyrus IMAP]
+ Syncroton --> |Contacts over CardDAV|IMAP[Cyrus IMAP]
+ Syncroton --> |Calendars over CalDAV|IMAP[Cyrus IMAP]