updated layout for webmail and added http dns letsencrypt

README.md

@@ -23,8 +23,11 @@ a Python venv + separate services.
   filter-rule management, and PGP (OpenPGP encrypt/decrypt/sign/verify) and S/MIME
   (sign/verify) support per mailbox.
 - **Admin dashboard** (`/pymta-manager`) — manage domains, senders, mailboxes, DKIM
-  keys, IP whitelisting, TLS (self-signed or Let's Encrypt via DNS-01: Cloudflare,
-  Route53, DigitalOcean, Google Cloud DNS), and review email + auth logs.
+  keys, IP whitelisting, TLS (self-signed/custom, or up to two simultaneous Let's
+  Encrypt certificates — DNS-01 via Cloudflare/Route53/DigitalOcean/Google Cloud DNS, and
+  HTTP-01 for domains you don't manage DNS for, optionally covering the server's own IP
+  too — independently assignable per listener, e.g. HTTP-01 for mail and DNS-01 for the
+  dashboard), and review email + auth logs.
 - **Security hardening built in** — CSRF protection, security headers (CSP, X-Frame-
   Options, etc.), Cloudflare-aware trusted-proxy IP resolution, login rate limiting and
   account lockout, TOTP + WebAuthn/passkey MFA (admin and mailbox owners), and automatic
@@ -83,7 +86,9 @@ IMAP `143`, direct-TLS IMAP `993` — the real standard mail ports, so binding t
 directly needs root or `setcap` (see below), which the Docker deployment already
 handles for you. Admin/webmail HTTP `5000` / HTTPS `5001` stay deliberately
 non-privileged; put a reverse proxy or your own `80`/`443` mapping in front of those if
-you want the dashboard on standard web ports too.
+you want the dashboard on standard web ports too. Port `80` is also used, but only
+transiently, if you enable Let's Encrypt's HTTP-01 challenge (see below) — the same
+setcap/root/Docker rule applies to it as to the mail ports.
 
 ## Build
 
@@ -92,7 +97,7 @@ cd mailgoserver
 go build -o mailgoserver .
 ```
 
-## Bind ports 25/143/465/993 without root
+## Bind ports 25/143/465/993 (and 80, for Let's Encrypt) without root
 
 The default SMTP/IMAP ports are the real standard ones now, so running the binary
 directly (not via Docker) needs one of:
@@ -103,7 +108,10 @@ sudo setcap 'cap_net_bind_service=+ep' ./mailgoserver
 
 or run it as root, or via the systemd unit below (which grants the capability instead
 of running as root). Same purpose as `script_setup_py_environment.sh`'s `setcap` step
-on the Python venv, applied to the compiled binary instead. **Not needed for the Docker
+on the Python venv, applied to the compiled binary instead. `cap_net_bind_service`
+covers every port under 1024, so this one grant is also what lets Let's Encrypt's
+HTTP-01 challenge bind :80 (only while an obtain/renew is actually running, see the
+Let's Encrypt page below). **Not needed for the Docker
 deployment** — those containers run as root, so binding 25/143/465/993 directly just
 works with no extra setup.
 
@@ -152,6 +160,42 @@ See [`docker-deploy/`](docker-deploy/) — a standalone image and one that bundl
 latest rspamd in the same container, both via a single `docker-compose.yml` using
 Compose profiles.
 
+## Certificates
+
+Three independent listeners need a TLS certificate: SMTP direct-TLS (465), IMAP
+direct-TLS (993), and the admin/webmail HTTPS UI (5001). Each can be assigned a
+different one, from the admin dashboard's **Settings** page (TLS/SSL Configuration
+card):
+
+- **Custom** — self-signed by default (generated on first run), or your own uploaded
+  cert/key.
+- **Let's Encrypt (DNS-01)** — automatic, needs a supported DNS provider (Cloudflare,
+  Route53, DigitalOcean, Google Cloud DNS). Configure on the dashboard's **Let's
+  Encrypt** page.
+- **Let's Encrypt (HTTP-01)** — automatic, needs no DNS provider at all, only port 80
+  reachable from the internet — the right choice for a domain whose DNS isn't hosted
+  anywhere this server can automate. Once enabled (needs a restart to take effect), this
+  binds a small HTTP server that stays up for the life of the process — hit it directly
+  (`curl http://your-host/`) and you should get a plain `200 ok`, which is the easiest
+  way to confirm your router/reverse-proxy port-forwarding actually reaches this host,
+  independent of running a real obtain. Optionally also covers the server's own public IP
+  address on the same certificate (autodetected, or a manual override) — note this forces
+  Let's Encrypt's `shortlived` certificate profile (the only one that currently allows IP
+  identifiers), so those certificates are valid for only ~6 days and renew far more often,
+  handled automatically. Configure on the **Let's Encrypt** page. The local bind port
+  defaults to `80` (`[Server] HTTP_LETSENCRYPT_PORT`) — change this only if something
+  ahead of this host (a router or reverse proxy) forwards the internet-facing port 80 to
+  a different local port; Let's Encrypt itself always connects to port 80, there's no way
+  to make it use a different port on the CA side.
+
+A common setup: HTTP-01 for the mail listeners (SMTP-TLS/IMAP-TLS) since mail clients
+rarely validate hostnames strictly, paired with DNS-01 (or a real custom cert) for the
+web UI where browsers do. Both Let's Encrypt certificates can be enabled at once — they're
+obtained and renewed independently — and switching which listener uses which needs a
+restart to take effect. All of this is also settable directly in `settings.ini`: see the
+`[TLS]` (`smtp_tls_cert`/`imap_tls_cert`/`web_https_cert`), `[LetsEncrypt]` (DNS-01), and
+`[LetsEncryptHTTP]` (HTTP-01) sections.
+
 ## Admin dashboard login
 
 First run seeds one account: username `admin`, password `Password123!`. Logging in