Session-start note (ground truth + design questions): https://projects.knownelement.com/issues/696#note-4086 No duplicate ticket: #696 (child of umbrella #694) already covers PMG deploy + MX cut-over; session gated on #696.
77 lines
3.3 KiB
Markdown
77 lines
3.3 KiB
Markdown
# Questions — v7 (current round)
|
||
|
||
Round v6 carried below (badge Q4 still open). New this round: the
|
||
Proxmox Mail Gateway pair (#696, child of #694) design questions
|
||
PQ1–PQ7. Recommended defaults are stated per question — answering
|
||
"defaults fine" (or naming exceptions) is enough.
|
||
|
||
## PMG round (#696) — awaiting answers
|
||
|
||
**PQ1. Mail domains + backend target?**
|
||
Which domains' mail should flow through the PFV PMG pair (e.g.
|
||
knownelement.com, turnsys.com, thefnf.net)? And what sits behind PMG
|
||
as the delivery target — the Cloudron VPS in Reston VA? If so, which
|
||
hostname should PMG smarthost to (e.g. `mail.<domain>`)?
|
||
*Ground truth: the internal Technitium `knel.net` zone has no MX
|
||
records; public MX lives at OVH/Cloudron (founder DNS).*
|
||
|
||
**PQ2. Inbound path from the internet?**
|
||
Recommendation: edge DNAT of SMTP :25 → both PMG nodes (LAN IPs),
|
||
PMG filters then relays to the Cloudron backend. Which edge does the
|
||
DNAT live on today — the rrinfra Cisco (existing), and are there any
|
||
existing mail port-forwards I should be aware of?
|
||
|
||
**PQ3. Outbound smarthost?**
|
||
Should LAN/Tailscale systems (hosts, VMs, appliances) relay outbound
|
||
mail through PMG? If yes, confirm authorized source subnets for the
|
||
allowlist. And Cloudron's own outbound: keep it direct (as today) or
|
||
route it back through PMG too?
|
||
|
||
**PQ4. VM placement + sizing?**
|
||
Recommendation: 2 VMs, each 2 vCPU / 4G RAM / 32G system disk (PMG is
|
||
light). PMG-01 on tsys4, PMG-02 on tsys6 — honoring the standing
|
||
ruling that tsys6/7 use USB storage only (PMG disks are small, fits
|
||
fine). VMIDs: next free in the production range unless you want
|
||
specifics. OK?
|
||
|
||
**PQ5. Native PMG cluster or independent pair?**
|
||
Recommendation: PMG native clustering (config + quarantine DB
|
||
replicates between the two), managed strictly serial with a health
|
||
gate between hops per the blue/green house rule. OK?
|
||
|
||
**PQ6. TLS from the fleet CA (#697)?**
|
||
Recommendation: issue certs for `pmg-01.knel.net` / `pmg-02.knel.net`
|
||
from the tsys-ca intermediate for the admin UIs; SMTP keeps
|
||
opportunistic TLS (external senders never see our internal CA, so no
|
||
interop risk). OK?
|
||
|
||
**PQ7. Quarantine + admin notifications?**
|
||
Defaults I'd apply unless you say otherwise: quarantine retention 7
|
||
days, daily quarantine digest to your admin address — **which address
|
||
should receive quarantine reports and PMG alerts?**
|
||
|
||
## Carried from v6 — still open
|
||
|
||
**Q4. Second human approver in gitea?**
|
||
**A (from v6):** Founder: "planned for very near future." Until
|
||
granted + named, KNEL/access-roster merges are IMPOSSIBLE by design
|
||
(fail-safe). Does not block code/deploy work.
|
||
|
||
## Carried from v6 — resolved
|
||
|
||
**Q1. Door actuator path?** Same 2018 hardware — usbrelay strike on
|
||
pfvsvrpi (16c0:05df); usbrelay tool install is ticket-gated #356.
|
||
|
||
**Q2. Reader model + badge format?** Both readers = 13ba:0018 PCPlay
|
||
PCP-BCG4209; pfvsvrpi aarch64/event0, ultix-field x86_64/event15;
|
||
24-byte records; 10-digit decimal + Enter.
|
||
|
||
**Q3. Badge whitelist home?** HA-side whitelist, materialized as
|
||
separate repo KNEL/access-roster (see Q5).
|
||
|
||
**Q5. Two-approval gate on roster home?** RESOLVED 2026-09-02 —
|
||
founder ruling: roster is 100% separate. Built: KNEL/access-roster
|
||
(private, PR-only + two human approvals); holds roster/badges.yaml.
|
||
doorman code repo de-gated. HA consumption owned by the pfv-bms
|
||
session.
|