Proxmox Mail Gateway 9.0

Hintergrund: Warum ein Major-Release?

Ein Versionssprung von 8.x auf 9.0 ist nicht trivial. Er signalisiert größere Systemänderungen, Anpassungen im Stack und gelegentlich Inkompatibilitäten. Bei Proxmox Mail Gateway 9 liegt der Fokus klar darauf, die Infrastruktur zukunftssicher aufzustellen, moderne Web-Technologien und Identitätsstandards besser zu integrieren und gleichzeitig eine solide Basis mit aktuellen Sicherheitsstandards zu bieten.

Die offizielle Roadmap nennt als Motivationen: Umstellung des Kernsystems auf Debian Trixie, modernere Web-Frontends (insbesondere für mobile Geräte) und Verbesserungen bei der Authentifizierung mit OpenID Connect. Im Changelog werden zahlreiche Detailverbesserungen genannt, etwa beim Rule-System, API-Fehlerkorrekturen, Anpassung an geänderte MIME-Typ-Bezeichnungen und Validierungen in OIDC-Konfigurationen. Das Ziel ist: bestehende Installationen mit möglichst geringer Unterbrechung hin zu einer modernisierten Architektur überführen — mit Mehrwert für Bedienbarkeit, Sicherheit und Flexibilität

Technische Neuerungen im Detail

1. Basis-Umstieg auf Debian Trixie & Postfix-Anpassungen

PMG 9.0 nutzt Debian Trixie als Unterbau. Damit sind viele Pakete, Libraries und Systemkomponenten auf einem neueren Versionsstand. 

Wesentlich: Die postfix-MTA-Komponenten im Proxmox Mail Gateway wurden an die upstream-Änderungen angepasst. Dazu gehört u. a.:

• Anpassung des application/x-ms-dos-executable MIME-Typs zu application/vnd.microsoft.portable-executable / application/x-msdownload, passend zu Änderungen im Debian-Umfeld. Bestehende Regeln mit .exe-Filtern werden automatisch migriert

• Das Paket pmg-api aktiviert nun nach der Installation das clamav-freshclam-Daemon (der in neueren Debian-Versionen nicht automatisch aktiviert wird).

• Änderungen im Format der Debian-Repositories für das Enterprise-Repo (Deb822-Format) wurden berücksichtigt.

2. Moderne Quarantäne UI – speziell für Mobile Devices

Ein großer Fokus liegt auf der neuen Quarantäne-Oberfläche für mobile Browser. Diese ist mit dem Rust-basierten Yew-Framework implementiert, was Performance und Responsivität verspricht. Für normale Desktops wird weiterhin eine klassische Quarantäne-Anzeige angeboten, zusätzlich mit einem Button zum Wechsel zur mobilen Ansicht, falls das Display zu klein ist. Besonders relevant: Der Quarantäne-Zugriff für Endanwender (z. B. zur Freigabe / Löschung von Spam) wird dadurch deutlich benutzerfreundlicher – insbesondere über Smartphones und Tablets.

3. Verbesserte OpenID Connect / SSO und Authentifizierungsrealms

Die OIDC-Integration, die schon ab PMG 8.2 verfügbar war, wurde in Version 9.0 weiter durchdacht:

• Der bisher harte „pmg“-Realm wird nicht mehr zwangsläufig als Standard gesetzt. Administratoren können einen beliebigen Realm als Default definieren.

• Die Konfiguration von OpenID-Connect-Reichen ist nun über die GUI möglich, inklusive Parametern wie username-claimund Standardrollen für neu erstellte Nutzer.

• Validierungen für client-id und client-keywurden entsprechend RFC-Vorgaben verschärft.

• In einem Multi-Node-Umfeld wurde ein Fehler behoben, bei dem sich ein Benutzer zuerst auf einem Sekundärknoten nicht anmelden konnte, wenn OIDC mit Auto-Creation aktiviert war.

5. AppArmor 4.1 & Sicherheitsaspekte

Version 9 bringt AppArmor 4.1 ins Spiel. Damit einher können Kompatibilitätsprobleme mit älteren Profilen auftreten – insbesondere bei Paketen außerhalb des Kern-Stacks, wie ClamAV oder Druckdiensten.

Ein Workaround: Profile können so umgeschrieben werden, dass sie den ABI-Modus 3.0 erlauben (z. B. mit der Zeile abi <abi/3.0>,). Außerdem wurde ein XSS-Problem in der HTTP-Proxy-Einstellung beseitigt, das als Sicherheitslücke klassifiziert wurde (Proxmox Security Advisory PSA-2025-00015-1). Für Systemadministratoren heißt das: Nach dem Upgrade sind Tests in Bezug auf AppArmor-Profile dringend notwendig – insbesondere bei Zusatzdiensten, benutzerdefinierten Plugins oder externen Komponenten. 

Empfehlungen für den Upgrade-Prozess

Ein größeres Versionsupgrade erfordert sorgfältige Planung. Hier einige Hinweise:

1. Backup & Tests vorab
   Erstellen Sie vollständige Konfigurations- und Systembackups. Testen Sie das Upgrade in einer Staging-Instanz, sofern möglich.

2. Kompatibilitätsprüfung von Regeln und Templates
   Vergleichen Sie Ihre angepassten Postfix / Rule-Templates mit den neuen Versionen. Nicht selten lohnt sich eine manuelle Anpassung oder Neuformulierung alter Regeln, anstatt stur Migrationen durchzuführen.

3. Überprüfung von AppArmor-Profilen
   Testen Sie speziell Dienste außerhalb des Kern-Stacks (z. B. ClamAV, Plugins). Nutzen Sie ggf. Kompatibilitätsanpassungen mit ABI 3.0.

4. Quarantäne-UI testen (Desktop & Mobile)
   Insbesondere wenn Admins oder Anwender regelmäßig auf Quarantäne-Mails über mobile Geräte zugreifen – testen Sie die neue Yew-basierte Oberfläche.

5. OIDC / IAM-Integration validieren
   Falls Sie schon OpenID Connect oder externe Identitäten verwenden: validieren Sie Realm-Konfigurationen, client-id, Claim-Zuordnungen und Rechtezuweisungen in einer Testumgebung.

6. Monitoring & Logging beobachten
   Nach dem Upgrade: Logs sowie Funktionen wie Quarantäne-Reports, API-Endpunkte und Mail-Fluss genau beobachten – frühzeitig Probleme erkennen.