Souvera Shield

Changelog

Changelog

Legende: Neu = neue Funktionen, Geändert = Änderungen an bestehendem Verhalten oder Design, Behoben = Fehlerbehebungen, Entfernt = entfernte Funktionen, Sicherheit = sicherheitsrelevante Änderungen. Neueste Version steht immer zuoberst.

v3.5.0 – 2026-06-20

Kritischer Fix: Mail-Test-Versand (550 Relay not allowed)

Souvera Shield legt das Postfach postmaster@<Kunden-Domain> jetzt automatisch über die Stalwart-Management-API an (JMAP, POST /api mit den Admin-Credentials aus souvera_central.stalwart_admin_user / …_admin_password) und versendet den Reputations-Test per SMTP-AUTH als dieses Postfach. Damit akzeptiert Stalwart den externen provider.tools-Empfänger (authentifizierte Submission), und MAIL FROM = postmaster@Kunden-Domain sorgt für korrektes SPF-/DKIM-/DMARC-Alignment.
Standard-Port ist jetzt 587 (Submission mit AUTH); Override weiterhin über souvera_central.stalwart_smtp_port (465 = Implicit-TLS).
Das Postfach-Passwort wird zufällig generiert, verschlüsselt in der App-Config gespeichert und bei AUTH-Fehlern automatisch über die Management-API neu gesetzt (selbstheilend, genau ein Retry).
Hinweis: Der frühere Versuch über POST /api/principal schlug fehl, weil Stalwart ≥ v0.16 die alte REST-Route entfernt hat – die Account-Verwaltung läuft dort über JMAP (x:Account/set).
Neue Fehler-Stage provision: Diagnosen benennen exakt, ob die Management-API, die Domain-Anlage in Stalwart oder die Admin-Credentials das Problem sind.

Neu: Erweiterte Reputations-Verwaltung (alles echte Daten, kein Fake)

Zentraler Reputations-Score 0–100 – gewichtet aus DMARC-Pass-Raten, letztem Mail-Test, Blacklist-Status (provider.tools, IP und Domain), Infrastruktur-Checks und offenen Vorfällen. Komponenten ohne Datenbasis werden ausgewiesen statt geschätzt; Score-Verlauf als tägliche Snapshots.
Provider-Reputation für Google, Microsoft, Yahoo und GMX/Web.de – Volumen und DKIM-/SPF-Pass-Raten aus den DMARC-Reports des jeweiligen Providers.
Zustellbarkeits-Checks mit Problem-Erklärung und Lösungsweg je Check: SPF-Record, DMARC-Policy, SPF-/DKIM-Alignment, DKIM-Signatur, PTR/FCrDNS, HELO-Banner, STARTTLS, MTA-STS (inkl. Policy-Abruf), TLS-RPT, BIMI, One-Click-Unsubscribe sowie Blacklist-Prüfung der ausgehenden IP und der Domain (120+ DNSBLs).
Quellen-Klassifizierung der DMARC-Versandquellen: legitim / unbekannt / potenziell missbräuchlich.
Anomalie-Erkennung: Volumen-Spikes (mögliche Konto-Kompromittierung) und Quellen ohne jegliche Authentifizierung.
Automatische Reputations-Vorfälle mit Historie, Ursache, betroffener Domain/IPs, Empfehlung und Maßnahmen-Protokoll; Dedupe, Auto-Resolve bei behobenem Zustand, Wiedereröffnung bei Rückfall, manuelles Auflösen im Dialog. Täglicher Hintergrund-Job + „Analyse jetzt ausführen“-Button.
Complaint-/Feedback-Loop-Auswertung – ehrlich: Anzahl forensischer DMARC-Reports (RUF) + RUF-Konfigurationsstatus; für Google/Microsoft-Beschwerderaten wird auf Postmaster Tools/SNDS verwiesen (keine öffentliche API, keine erfundenen Zahlen).
Neue API-Endpunkte unter /api/reputation/* (overview, providers, checks, sources, incidents, analyze) – geschützt über die souvera-admins-Gruppe. Zwei neue Tabellen: souvera_shield_incident, souvera_shield_score_snap.
Bestehende provider.tools-Integration, DMARC-Reports, SPF-/DKIM-Auswertung, Mail-Tests und das Seiten-Design bleiben unverändert.

v3.4.3 – 2026-02-16

Kritischer Fix

Der Reputations-Mail-Test läuft ab jetzt zwingend über den Stalwart-Server des Kunden. v3.3.9 hatte fälschlich Nextclouds eigene SMTP-Konfiguration verwendet – provider.tools misst dann die IP, PTR, SPF, DKIM und DMARC dieses generischen Servers und liefert damit ein völlig irrelevantes Ergebnis für die Kunden-Domain. Ab v3.4.3 verbindet sich Souvera Shield direkt mit dem Stalwart-Host aus souvera_central.stalwart_api_url und sendet die Test-Mail von no-reply@<Kunden-Domain> aus.
Optionaler Port-Override über souvera_central.stalwart_smtp_port (Default: 25 – MTA-zu-MTA-Kanal, Trust-basierter Relay ohne SMTP-AUTH).
Souvera Shield authentifiziert bewusst NICHT gegenüber Stalwart – der Stalwart-Management-Nutzer ist CLI-only und kann keine Mails versenden. Stattdessen wird die Nextcloud-IP als vertrauenswürdig behandelt (dieselbe Trust-Grenze, die auch Souvera Central selbst für seinen ausgehenden Mailverkehr nutzt).

Diagnose

Fehlermeldungen verweisen jetzt auf Stalwart-Konfiguration (statt fälschlich auf Nextclouds Mail-Einstellungen). Beispiel: Wenn Stalwart AUTH erwartet, weist die Meldung darauf hin, dass die Nextcloud-IP als Trust-Relay eingetragen werden muss ODER der Port auf 25 gesetzt werden soll.

v3.4.2 – 2026-02-16

Behoben

Dashboard-Widget zeigte nie Quarantäne-Mails an, obwohl die App-Ansicht welche listete. Das Widget fragte PMG ohne Datumsbereich ab und bekam damit nur die Mails von heute. Ab sofort verwendet das Widget dasselbe 90-Tage-Fenster wie die reguläre Übersicht.
„Übersicht", „Datei-Quarantäne" und „Virus-Quarantäne" zeigten „Request failed with status code 404". Ursache: Das Frontend rief API-Adressen mit Bindestrich auf (/api/file-quarantine), während das Backend die Adressen mit Unterstrich anbietet (/api/file_quarantine). Frontend an das Backend angeglichen – alle drei Views laden jetzt sauber.

v3.4.1 – 2026-02-16

Behoben

Status-Chips waren im hellen Modus immer noch blass. Der Fix in v3.4.0 benutzte Nextclouds Theme-Farbvariablen --color-success/warning/error als Hintergrund – die sind aber in NC's Standard-Light-Theme sehr pastellig, wodurch weißer Text darauf kaum lesbar war. Jetzt werden explizite, gesättigte HSL-Farben verwendet (kräftiges Grün / Bernstein / Rot), unabhängig vom NC-Theme, plus ein leichter Text-Shadow zur zusätzlichen Definition.
Im dunklen Modus wird eine leicht hellere Variante genutzt, damit die Chips nicht überstrahlen.

v3.4.0 – 2026-02-16

Behoben

Status-Chips (PASS/FAIL, Score, „Abgeschlossen", „Fehler", DKIM/SPF/DMARC) waren im hellen Modus kaum lesbar. Text- und Hintergrundfarbe hatten den gleichen Farbton mit sehr geringer Sättigung. Ab sofort werden Status-Chips mit einem satten Grün/Orange/Rot als Hintergrund und weißem Text dargestellt – klar erkennbar in beiden Modi.
Dashboard-Widget-Icon war komplett unsichtbar (leerer Rahmen anstelle des Schild-Symbols). Ursache: die separate SVG-Datei hatte eine leicht abweichende Zeichenfläche; jetzt wird sie 1:1 aus der Menü-Version abgeleitet (nur mit umgekehrter Farbe), sodass sie garantiert korrekt rendert.

v3.3.9 – 2026-02-16

Behoben

Reputations-Mail-Test verlangte Konfiguration, die es gar nicht geben konnte. Souvera Shield ging bisher davon aus, dass unter souvera_central.stalwart_admin_user ein SMTP-fähiger Mail-Account hinterlegt ist – tatsächlich steht dort aber der Stalwart-Management-Nutzer (z. B. admin), der keinen Mail-Versand kann. Ergebnis: Der Test brach mit einer verwirrenden Konfig-Fehlermeldung ab.

Geändert

Der Mail-Test nutzt jetzt die gleichen SMTP-Einstellungen wie Nextcloud selbst. Die Werte, die der Administrator ohnehin für Passwort-Reset- und Benachrichtigungs-Mails unter „Verwaltung → Grundeinstellungen → E-Mail-Server" gesetzt hat, werden 1:1 übernommen (Server, Port, Verschlüsselung, Benutzername/Passwort, Absender-Adresse).
Damit reflektiert der Reputations-Score exakt den Zustand des Servers, über den auch alle anderen Souvera-System-Mails laufen – kein Konfigurations-Setup mehr in Souvera Central nötig.

Entfernt

Die früheren Config-Keys souvera_central.stalwart_admin_user, souvera_central.stalwart_admin_password, souvera_central.stalwart_api_url, souvera_central.stalwart_smtp_port werden für den Mail-Test nicht mehr gelesen. Souvera Central darf sie weiter für andere Zwecke nutzen; Shield ignoriert sie ab jetzt.

Voraussetzung: Nextclouds SMTP-Einstellungen müssen gesetzt sein (Verwaltung → Grundeinstellungen → E-Mail-Server). Ist das nicht der Fall, weist die Diagnose-Meldung darauf hin.

v3.3.8 – 2026-02-16

Behoben

Icon-Farbe im Dashboard-Widget passte nicht zum Modus: Das Widget nutzte bisher das (weiße) Menü-Icon. Im hellen Modus war es dadurch unsichtbar; im dunklen Modus wurde es durch den Nextcloud-CSS-Filter falsch schwarz gefärbt. Das Widget zeigt jetzt ein eigenes, dunkles Icon (img/dashboard.svg), das Nextcloud im dunklen Modus automatisch in Weiß umkehrt.

Ergebnis nach diesem Update:

Menü-Icon im hellen Modus: weiß · im dunklen Modus: schwarz (passt zum farbigen Souvera-Sidebar-Hintergrund).
Dashboard-Widget-Icon im hellen Modus: schwarz · im dunklen Modus: weiß (passt zum normalen Widget-Hintergrund).

v3.3.7 – 2026-02-16

Behoben

Dashboard-Widget zeigte dauerhaft einen Loading-Spinner: das Widget implementierte nur die alte Dashboard-API. Modernere Nextcloud-Versionen (27.1+) bleiben ohne die neue IAPIWidgetV2-Schnittstelle im Ladezustand hängen, wenn die Quarantäne leer ist. Das Widget liefert ab sofort einen expliziten Leer-Zustand („Deine Quarantäne ist derzeit leer.") und beendet damit den Spinner korrekt.
Kein Icon neben dem Widget-Titel: die Widget-CSS-Klasse verwies auf eine nicht existente Klasse. Die App liefert das Icon jetzt als absolute URL zum appicon.svg, sodass es in allen Themes (hell/dunkel/High-Contrast) und auf mobilen Clients sichtbar ist.

Neu

Geändert

v3.3.6 – 2026-02-16

Geändert

Kein zusätzlicher Setup-Schritt mehr: Souvera Shield verwendet für den Reputations-Mail-Test jetzt den scadmin@-Service-Account, den Souvera Central ohnehin bereits pflegt. Die in v3.3.5 verlangten Extra-Keys souvera_central.stalwart_mailtest_user/_password sind nicht mehr nötig.
Diagnose-Meldungen bei fehlgeschlagener SMTP-Auth zeigen jetzt auf die drei Souvera-Central-Keys (stalwart_api_url, stalwart_admin_user, stalwart_admin_password) und weisen zusätzlich darauf hin, dass ein Fehler an dieser Stelle auch andere Souvera-Dienste betrifft — die Diagnose führt schneller zur Ursache.
MAIL FROM ist ab sofort die scadmin-Adresse selbst. Stalwarts Sender-Alignment ist damit automatisch erfüllt (der Account sendet unter seiner eigenen Identität, keine 501-Rejects mehr).

Entfernt

Die Config-Keys souvera_central.stalwart_mailtest_user und souvera_central.stalwart_mailtest_password (v3.3.5) werden nicht mehr gelesen. Sie können gefahrlos entfernt werden.

Behoben

501 Sender Rejection beim „Reputation jetzt testen"-Klick: Stalwart wies den Absender postmaster@souvera.eu zurück, weil der SMTP-AUTH-Nutzer diese Adresse nicht in seiner Identität führte. Fix: Absender = SMTP-AUTH-Nutzer selbst (scadmin@…).

v3.3.5 – 2026-02-16

Geändert

Wichtige Korrektur: Stalwarts REST-Management-API wird seit v0.16 durch JMAP ersetzt — die in v3.3.4 versuchte Auto-Provisionierung via POST /api/principal funktioniert deshalb nicht (404). Statt weiterhin am REST-Endpoint zu bauen, geht Shield jetzt einen sauberen und ehrlichen Weg: Zwei zusätzliche Config-Keys, die der Hoster einmalig setzt.
Neue Config-Keys in Souvera Central (config.php): souvera_central.stalwart_mailtest_user und souvera_central.stalwart_mailtest_password. Der Hoster erstellt einmalig einen Send-Account in Stalwarts Admin-UI (Principals → Add Individual, 2 Minuten) und trägt Zugangsdaten in die beiden Keys ein.
Diagnose-Meldungen wurden auf das neue Modell umgestellt: alle Fehler-Stages (config, connect, starttls, auth, mail-from, rcpt-to, data) nennen jetzt entweder den passenden Config-Key oder den Admin-UI-Pfad.

Entfernt

Klassen StalwartAdminClient und MailTestPrincipalStore (v3.3.4-Kern) wurden zurückgezogen — sie basieren auf einer nicht mehr existierenden REST-API. Die Tests dazu ebenfalls.

v3.3.4 – 2026-02-16

Neu

Der Reputations-Mail-Test provisioniert seinen Send-Absender jetzt vollautomatisch im Stalwart. Beim ersten Test für eine Domain erzeugt Shield via Stalwart-Management-API einen dedizierten Principal shield-mailtest@<domain> (bcrypt-gehashtes Passwort), speichert die Zugangsdaten verschlüsselt in Shields eigenem App-Config und verwendet sie ab dann für den SMTP-Versand.
Weil Shield unter der eigenen Identität des shield-mailtest-Principals sendet (MAIL FROM = seine eigene Adresse), gibt es keine sender-alignment-Probleme mehr – Stalwart akzeptiert den Versand ohne Sonder-Rechte oder Alias-Konfiguration.
Falls Stalwart-Admin den Principal manuell entfernt, greift beim nächsten Test automatisch ein Reprovisioning (bei SMTP-AUTH-Fehler wird ein frischer Principal angelegt).

Geändert

Die Diagnose-Meldungen wurden auf das neue Modell umgestellt: SMTP-AUTH-Fehler verweisen jetzt auf den shield-mailtest-Principal und die Management-API-Rechte des Admin-Users, nicht mehr auf den Admin selbst als Absender.

Sicherheit

Der Principal-Passwort-Wert liegt im Nextcloud-App-Config verschlüsselt (Symmetric, über OCP\Security\ICrypto). Nur der Bcrypt-Hash landet im Stalwart, nicht der Klartext.

v3.3.3 – 2026-02-16

Geändert

Der Standard-SMTP-Port für den Mail-Test ist jetzt 465 (SMTPS / implicit TLS) statt 587. Grund: Souvera Stalwart hört im Standard-Deployment auf 465 (analog zu Souvera Mail). Damit funktioniert der Mail-Test ab v3.3.3 ohne zusätzliche Port-Konfiguration.
Der Config-Key souvera_central.stalwart_smtp_port bleibt bestehen – wer einen abweichenden Port nutzt (25 plain, 587 STARTTLS), setzt ihn per occ config:system:set.
Bei Port-465-Verbindungen wird implicit-TLS mit relaxter Zertifikatsprüfung (self-signed toleriert) verwendet – funktioniert also weiterhin gegen interne Stalwart-Instanzen mit selbst-signiertem Zertifikat.

v3.3.2 – 2026-02-16

Geändert

Der Mail-Test verträgt jetzt lokale Stalwart-Instanzen mit selbst-signiertem Zertifikat: die TLS-Verschlüsselung wird opportunistisch verhandelt – wenn Stalwart STARTTLS in der EHLO-Antwort anbietet, wird verschlüsselt (Zertifikatsprüfung deaktiviert, da interner Kontext), sonst wird plain weitergesendet. Kein Handshake-Absturz mehr an selbst-signierten Certs.
Der SMTP-Port ist optional konfigurierbar über den neuen config.php-Key souvera_central.stalwart_smtp_port (Standard 587). Für Instanzen, die intern auf Port 25 lauschen, reicht ein einziger Eintrag.
Port 465 (SMTPS/implicit TLS) wird weiterhin unterstützt – ebenfalls mit relaxter Zertifikatsprüfung, damit selbst-signierte Certs kein Blocker sind.

Neu

Debug-Log-Zeilen für den Mail-Test: Fällt STARTTLS aus (weil vom Server nicht angeboten oder Handshake gescheitert), erscheint eine warning-Zeile im nextcloud.log mit Host/Port und dem konkreten Grund – ohne den Test-Ablauf abzubrechen.

v3.3.1 – 2026-02-16

Geändert

Der Reputations-Mail-Test übernimmt die Stalwart-Zugangsdaten jetzt vollautomatisch aus Souvera Central (drei bereits vorhandene config.php-Keys: souvera_central.stalwart_api_url, _admin_user, _admin_password). Es müssen keine zusätzlichen Nextcloud-App-Config-Keys mehr gesetzt und kein App-Passwort im Stalwart-Admin manuell erzeugt werden.
Der SMTP-Host wird automatisch aus stalwart_api_url abgeleitet (Hostname), verwendet Port 587 mit STARTTLS und authentifiziert sich mit der Stalwart-Admin-Identität. Weil das Admin-Konto die administrator-Rolle trägt, sendet Shield pro Test aus der jeweils zu prüfenden Domäne (postmaster@<domain>) – identisch zu vorher, aber ohne Extra-Konto.
Diagnose-Meldungen bei Fehlern nennen jetzt exakt die drei stalwart_*-Keys statt der bisherigen sechs mailtest_smtp_*-Keys.

v3.3.0 – 2026-02-16

Geändert

Der Reputations-Mail-Test verschickt die Test-Mail nicht mehr über den generischen Nextcloud-Mailer, sondern über einen dedizierten SMTP-Relay-Kanal (Souvera Stalwart) mit eigenem Postmaster-App-Passwort. Damit werden externe Empfänger (z. B. chk.provider.tools) zuverlässig angenommen – der bisherige „Relay-Policy"-Fehler entfällt.
Die Diagnose bei fehlgeschlagenem Test ist deutlich schärfer: sie zeigt jetzt die konkrete SMTP-Stufe an (connect, starttls, auth, mail-from, rcpt-to, data) und benennt den passenden Konfigurationsschlüssel, an dem der Hoster ansetzen muss.

Neu

Neue zentrale Konfigurationsschlüssel in Souvera Central (App souvera_central): settings.shield.mailtest_smtp_host, _port, _user, _password, _security (tls/ssl/none, Standard tls) und optional _from. Ohne diese Konfiguration meldet Shield beim Mail-Test klar: „Mail-Test-Relay nicht konfiguriert – bitte Hoster kontaktieren."

v3.2.0 – 2026-02-16

Geändert

Die alle 10 Minuten laufende Hintergrund-Abfrage nach neuen Quarantäne-Mails ist robuster: Wenn Proxmox Mail Gateway kurzzeitig nicht erreichbar ist (etwa während eines Neustarts oder eines TLS-Renewals), wiederholt Shield die Anfrage automatisch bis zu drei Mal mit ansteigender Wartezeit (200 ms → 1 s → 5 s), bevor die aktuelle Runde übersprungen wird. Anwender sehen dadurch keine ausgelassenen Benachrichtigungen mehr bei kurzen PMG-Ausfällen.
Wiederholt wird nur bei transienten Fehlern (5xx / Verbindungsabbruch). Dauerhafte Fehler wie „nicht autorisiert" (HTTP 401) oder „nicht gefunden" (HTTP 404) werden nicht wiederholt, um PMG nicht unnötig zu belasten.

v3.1.2 – 2026-02-16

Behoben

Beim Aufruf des Nextcloud-Dashboards oder der globalen Suche (Strg+K) konnte es zu der Fehlermeldung „Could not resolve OCP\IL10N! Class can not be instantiated?“ kommen. Ursache: Nextclouds Dependency-Injection-Container kann die Übersetzungs-Klasse nicht ohne App-Kontext auflösen. Das Dashboard-Widget und der Suchanbieter beziehen die Übersetzungen jetzt korrekt über die L10N-Factory – Dashboard und Suche funktionieren wieder zuverlässig.

v3.1.1 – 2026-02-15

Behoben

Beim Öffnen von Souvera Shield erschien kurz „Interner Serverfehler", danach fehlten Menüpunkte wie Reputation oder Datei-Quarantäne in der Seitenleiste. Ursache war das Inline-<script> im Mount-Template, das auf die CSP-Nonce-API zugreifen musste – deren Signatur sich zwischen Nextcloud-Minor-Versionen ändert und im aktuellen Cloud-Build einen Fatal auslöste. Der ganze inline-Script ist entfernt; die Feature-Flags (Admin/Souvera-Admin, Datei-/Virus-Quarantäne, Version, initialer View) werden jetzt als data-*-Attribute am Mount-Point ausgeliefert und vom Vue-Bootstrap synchron gelesen. Damit ist der CSP-Pfad vollständig umgangen.
Webpack publicPath auf 'auto' gesetzt – damit funktionieren Lazy-Chunks jetzt auch, wenn Nextcloud unter einem Sub-Pfad läuft (z. B. https://cloud/nextcloud/apps/…).
Interner Vue-Router leitet Navigation ebenfalls über @nextcloud/router::generateUrl() und stripped bei Popstate den Instanz-Prefix – Sub-Path-Setups laufen jetzt sauber.

v3.1.0 – 2026-02-15

Neu

Reputationsseite bekommt einen neuen Zeitverlaufs-Bereich (Timeline) mit zwei Chart.js-Diagrammen:
- Nachrichten pro Tag als Balkendiagramm.
- DKIM- und SPF-Pass-Rate im Zeitverlauf als Liniendiagramm.
Die Diagramme aggregieren die vorhandenen DMARC-Aggregate-Reports clientseitig – kein neuer Backend-Aufruf, kein zusätzlicher Server-Aufwand.
Der Zeitraum-Umschalter (7/30/90 Tage) steuert jetzt sowohl die Kennzahl-Kacheln als auch die Zeitverlaufs-Diagramme gemeinsam – die Ansichten bleiben immer synchron.

Geändert

Die Farben der Diagramme werden aus den Nextcloud-Theme-Variablen abgeleitet, sodass Light-/Dark-/High-Contrast- sowie Hoster-Themes automatisch mitgezogen werden.
Sprachdateien um 5 neue Strings ergänzt (DE Du, DE Sie, NL, EN GB): Timeline, Messages per day, Pass rate over time, Daily volume …, Not enough report data yet ….

v3.0.0 – 2026-02-15 (Major Release)

Neu

Komplett neues Frontend auf Basis von Vue 3 + @nextcloud/vue v9 gemäß Souvera Design System (SPA mit NcContent / NcAppNavigation / NcAppContent). Icons aus vue-material-design-icons, Dialoge über @nextcloud/dialogs. Damit sieht Souvera Shield ab sofort optisch und technisch aus wie Souvera Central.
Webpack-Buildpipeline (yarn build) mit lazy-geladenen Views (Splitchunks). Erstes Bundle ~ 560 KB, restliche Views werden bei Bedarf nachgeladen.
Design-Tokens aus src/styles/forms.css: 44 px Control-Höhe, --border-radius-large, --sc-field-gap/--sc-section-gap, sowie definierter Focus-Ring. Farben werden konsequent aus Nextcloud-Theme-Variablen bezogen – Light/Dark/High-Contrast und Hoster-Theming funktionieren „einfach".

Geändert

Der bisherige Vanilla-JS-Client (js/app.js) und die statische CSS-Datei sind entfallen. Templates rendern nur noch den Mount-Punkt für die Vue-App.
Feature-Flags (souvera-admin, admin, Datei-/Virus-Quarantäne aktiv) werden serverseitig über IInitialState ausgeliefert – die Navigation zeigt nur die Menüpunkte, die dem angemeldeten Benutzer zustehen.
Modal-Dialoge (Vorschau, Bestätigung, Mail-Test-Details) laufen jetzt über NcDialog mit sauberen Close-Buttons; ESC- und Backdrop-Klick funktionieren nativ.

Unverändert

Alle Backend-APIs (PMG-Client, Whitelist/Blacklist, Reputation Management, Audit-Log, Settings) sind funktional identisch zu v2.4.x – bestehende Automationen, PHPUnit-Regressionstests und alle wöchentlichen Background-Jobs laufen weiter unverändert.
PhpUnit: 17 Tests / 38 Assertions grün.

Migration

Kein manueller Schritt nötig – occ upgrade genügt. Die neuen JS/CSS-Assets liegen in js/ und css/main.css, die alte css/style.css und js/app.js sind entfernt.

v2.4.2 – 2026-02-15

Behoben

„Mail-Test jetzt starten" brach mit SQL-Fehler Data too long for column 'error_message' ab, sobald die neue präzise SMTP-Diagnose (mit Config-Hinweisen) länger als 512 Zeichen war. Die Spalte error_message wird durch die Migration Version2420Date20260215120000 auf TEXT vergrößert; zusätzlich kürzt der MailTestService die gespeicherte Diagnose defensiv auf max. 500 Zeichen, damit auch Instanzen ohne aktuelle Migration nicht mehr crashen.

v2.4.2 – 2026-02-15

Behoben

„Mail-Test jetzt starten" brach mit SQL-Fehler Data too long for column 'error_message' ab, sobald die neue präzise SMTP-Diagnose (mit Config-Hinweisen) länger als 512 Zeichen war. Die Spalte error_message wird durch die Migration Version2420Date20260215120000 auf TEXT vergrößert; zusätzlich kürzt der MailTestService die gespeicherte Diagnose defensiv auf max. 500 Zeichen, damit auch Instanzen ohne aktuelle Migration nicht mehr crashen.

v2.4.1 – 2026-02-15

Behoben

Das „Mail-Test-Details"-Modal ließ sich nicht mehr schließen (X, OK, Abbrechen alle ohne Wirkung). Der Schließen-Button schließt das Modal jetzt in jedem Fall, ESC funktioniert zusätzlich als Shortcut.

Geändert

Der „Mail-Test jetzt ausführen"-Fehler zeigt jetzt eine präzise Diagnose statt der rohen SMTP-Meldung. Häufige Ursachen (Relay-Policy des Nextcloud-Mailrelays, SPF-/Absender-Ablehnung, SMTP-Authentifizierung, TLS-/Verbindungsfehler) werden erkannt und mit konkreten Hinweisen zur Cloud-Konfiguration versehen (z. B. mail_smtpmode, Postfix smtpd_recipient_restrictions, PMG-Relaying).
Auf der Reputationsseite gibt es jetzt Pagination: 10 Aggregate-Reports pro Seite und 5 Top-Absender pro Seite mit Vor-/Zurück-Buttons und Seitenanzeige. Damit bleibt die Seite auch bei vielen Reports übersichtlich.

Neu

Nextcloud-Sprachdateien in vier Varianten:
- Deutsch (Du) – informell
- Deutsch (Sie) – formell
- Niederländisch
- Englisch (GB)
Nextcloud wählt die passende Datei automatisch anhand der Nutzer-Spracheinstellung.

v2.4.0 – 2026-02-15

Neu

Reputationsseite nutzt jetzt den vollständigen DMARC Analyzer von provider.tools statt eines einzelnen DNS-Snapshots. Auf Wunsch registriert Souvera Shield die Workspace-Domain per Klick, zeigt die dazu nötigen DNS-TXT-Einträge (Verifizierung + rua) mit Kopier-Knopf an und lässt die Verifizierung anschließend prüfen.
Neuer Statistik-Bereich: Nachrichten, empfangene Reports, DKIM-Pass-Rate, SPF-Pass-Rate sowie eine Übersicht der Top-Absender – umschaltbar zwischen 7, 30 und 90 Tagen.
Neuer Abschnitt „Aggregierte Berichte": Liste der von den Empfänger-Providern gesendeten DMARC-Aggregat-Reports mit Zeitraum, Nachrichtenanzahl, DKIM-/SPF-Erfolg und Policy.

Geändert

Die Aktions-Buttons in allen Tabellen (Spam-, Datei-, Virus-Quarantäne, Whitelist, Blacklist, Reputation) sind jetzt kompakte Icon-Buttons mit Tooltip. Der Text („Vorschau", „Freigeben", „Löschen", …) erscheint als Tooltip / Screenreader-Label – dadurch schneidet in der Tabelle nichts mehr ab.
Sofortiger Mail-Test: Schlägt der Versand fehl (fehlender API-Token, SMTP-Ablehnung, …), erscheint der Fehler direkt als Toast-Meldung. Es wird kein irreführender Erfolgshinweis mehr angezeigt und kein Fehler-Eintrag in der Test-Historie stehen gelassen.

Entfernt

Der bisherige „DMARC-Recheck" (einmaliger DNS-Lookup) ist entfallen. Er wird durch die kontinuierliche Reportauswertung des DMARC Analyzers ersetzt.

v2.3.3 – 2026-02-15

Geändert

Der API-Zugangsschlüssel für die Reputationsprüfung (provider.tools) wird jetzt ausschließlich zentral in Souvera Central verwaltet. Souvera Shield lädt den Schlüssel bei Bedarf, speichert ihn selbst aber nirgendwo mehr. Ein einmal in Central hinterlegter Token gilt automatisch für alle Souvera-Apps.

Entfernt

Der bisherige lokale Konfigurationsbefehl occ souvera_shield:set-provider-tools-token ist entfallen. Zum Setzen/Rotieren des Tokens dient künftig ausschließlich occ souvera:provider-token:set in Souvera Central.

Sicherheit

Der provider.tools-Token liegt nicht mehr in der App-Konfiguration von Shield, sondern nur noch verschlüsselt in Souvera Central. Damit gibt es nur eine einzige Stelle im System, an der dieses gemeinsame Geheimnis vorhanden ist.

v2.3.2 – 2026-02-14

Behoben

Mitglieder der Gruppe souvera-admins (die nicht gleichzeitig in souvera-users waren) sahen die App im Nextcloud-Menü nicht bzw. bekamen HTTP 404 auf allen App-Routen. Beim Einrichten der App wird nun automatisch beiden Gruppen der Zugriff gewährt.
Zugriffs-Middleware lässt jetzt sowohl souvera-users als auch souvera-admins durch (Server-Administratoren sowieso).

Wichtig für Deployment

Damit dieser Fix greift, muss nach dem Update wie üblich occ upgrade laufen (das erledigt Souvera als Hoster). Andernfalls bleibt die App im „Upgrade erforderlich"-Zustand und liefert weiterhin HTTP 404 aus.

v2.3.1 – 2026-02-14

Geändert

Menüpunkt DMARC & Mail test heißt jetzt Reputation.
Reputation-Seite ist nun in zwei klar getrennte Bereiche geteilt: DMARC (aktueller DNS-Zustand als Übersichtskarte) und Mail test (Historie + Sofort-Test-Button).
Es gibt keine Domain-Verwaltung mehr in der Oberfläche. Souvera Shield überwacht immer genau die eine Workspace-Domain, die durch die zentrale Konfiguration vorgegeben ist. Der Button „Domain hinzufügen" ist entfallen, ebenso die Aktivierungs-/Löschen-Buttons pro Domain.
Absender-Adresse für die Test-Mail wird nicht mehr im UI angezeigt/bearbeitet; sie wird aus der Konfiguration abgeleitet (standardmäßig postmaster@<domain>).

Behoben

Tabellen in Spam-Quarantäne, Anhang-Quarantäne, Virus-Quarantäne, Whitelist, Blacklist, Audit-Log und Übersicht hatten unregelmäßige Spaltenbreiten – Zeit-, Absender- und Betreff-Spalte teilten sich den Platz gleichmäßig, sodass der Betreff regelmäßig abgeschnitten wurde.
Tabellen sind auf schmalen Bildschirmen (Smartphone, Tablet quer) nicht mehr scrollbar/abgeschnitten. Ab < 640 px werden die Zeilen zu einzelnen Karten mit klaren Feld-Labels aufgeklappt (Card-Layout).
Sticky-Kopfzeile in den Tabellen konnte auf einigen Themes verschwommen wirken – entfernt.

v2.3.0 – 2026-02-14

Neu

Neuer Menüpunkt DMARC & Mail-Test für Mitglieder der Gruppe souvera-admins.
Domains zur DMARC-Überwachung hinzufügen (Absender-Adresse konfigurierbar, Standard postmaster@<domain>).
DMARC-, SPF- und DKIM-Records einer Domain per Klick über provider.tools prüfen und den Ist-Zustand direkt in der Tabelle sehen.
Anzeige, ob die Domain bei provider.tools verifiziert ist (rote Kennzeichnung „Nicht verifiziert" falls nicht).
Manueller Mail-Test pro Domain: Souvera Shield sendet über den Mailserver eine Test-Mail an provider.tools und holt sich das Ergebnis (SPF/DKIM/DMARC, Score) automatisch ab.
Wöchentlicher automatischer Mail-Test aller aktiven Domains, ausgeführt jeden Sonntag über den Nextcloud-Cron.
Historie aller Mail-Tests mit Filter nach Domain, Details-Ansicht und farblichem Score-Badge (grün ≥ 8, gelb 5–8, rot < 5).
Sichtbarer Versions-Footer am unteren Rand jeder Souvera-Shield-Seite.

Geändert

Zwei neue Hintergrund-Jobs eingeführt: Weekly Mail Test (Sonntag) und Poll Pending Mail Tests (alle 5 Minuten).

Sicherheit

Zusätzliche Middleware sperrt sämtliche DMARC- und Mail-Test-Endpunkte für Nutzer außerhalb der Gruppe souvera-admins (HTTP 403).
Der provider.tools-API-Token wird verschlüsselt in der App-Config gespeichert und ist über die Oberfläche nicht auslesbar.
Rückwärtskompatibilität mit vorhandenen Nextcloud-Admin-Rechten: Server-Administratoren behalten Zugriff auch ohne Mitgliedschaft in souvera-admins.

v2.2.2 – 2026-02-14

Erststand des Changelogs – fasst den bisherigen Entwicklungsstand zusammen. Künftige Änderungen werden als einzelne Versionen geführt.

Neu

Vollständige Neu-Umsetzung als native Nextcloud-App für Nextcloud 34, angepasst an das aktuelle Nextcloud-Design (Light-, Dark- und High-Contrast-Modus).
Zugriff auf Spam-, Virus- und Anhang-Quarantäne von Proxmox Mail Gateway direkt aus Nextcloud – kein PMG-Login mehr nötig.
Übersichtsseite mit Zähler-Kacheln je Quarantäne-Typ und den letzten Aktivitäten.
Vorschau von Quarantäne-E-Mails in einer Sicherheits-Sandbox (keine externen Ressourcen).
Freitextsuche und erweiterte Filter (Zeitraum, Score, Absender-Domain, Betreff).
Massenaktionen: Freigeben oder Löschen mehrerer E-Mails auf einmal, mit Bulk-Limit.
Persönliche Whitelist und Blacklist mit Wildcard-Unterstützung.
Deutsche und englische Übersetzung.
Dashboard-Widget mit den neuesten Quarantäne-Einträgen.
Globale Nextcloud-Suche integriert: Quarantäne-Einträge tauchen in Strg+F auf.
Nextcloud-Benachrichtigungen bei neuen Quarantäne-Einträgen (Glocke oben rechts).
CSV-Export für jede Quarantäne-Ansicht sowie für Whitelist/Blacklist.
Audit-Log für Administratoren mit Filtern, Sortierung, Freitextsuche und CSV-Export.
Hintergrund-Job (alle 10 Minuten) für frische Zähler und Benachrichtigungen.

Geändert

Layout und Theming vollständig auf Nextcloud-34-Standard umgestellt (App-Navigation, Content-Bereich, Design-Tokens).
Zugangsdaten zum Proxmox Mail Gateway werden zentral gepflegt und verschlüsselt gespeichert; sie sind in der Oberfläche nicht mehr sichtbar.
Globale Einstellungen (Modul-Aktivierung, Bulk-Limit, Notification-Rhythmus) werden aus Souvera Central gelesen – keine doppelte Pflege mehr.
Zugriff auf die App ist auf die Gruppe souvera-users begrenzt; alle anderen Nutzer sehen die App gar nicht.
Tabelle in allen Quarantäne-Ansichten mit fixem Layout: kein horizontaler Scroll-Sprung mehr beim Öffnen einer Zeile.

Behoben

Vorschau-Aufruf lieferte in Einzelfällen einen 400-Fehler beim Proxmox Mail Gateway – parameter-bereinigt.
Buttons „Freigeben" und „Löschen" reagierten unter bestimmten Umständen nicht – Ablauf und Fehlermeldungen überarbeitet.
Massenaktions-Leiste wurde nicht eingeblendet, wenn die Auswahl per Master-Häkchen erfolgte.
Konflikt mit der Nextcloud-Login-Seite, wenn im App-Manifest <navigation> ohne <id>-Tag angegeben war.
Leerer <repair-steps/>-Tag im Manifest führte zu einem globalen occ-Fehler – entfernt.
Übersetzungs-Dateien lösten einen array_merge-Fehler aus – JSON-Struktur korrigiert (Nesting unter translations).
Debug-Log-Spam durch die Verwendung veralteter Konfigurations-APIs behoben (Umstieg auf IAppConfig).
Fehler beim Aufruf von getValueString nach dem Wechsel auf IAppConfig beseitigt (korrektes Interface eingebunden).
Verwendung deprecateter Server-Zugriffe entfernt (moderne Dependency Injection statt OC::$server).

Entfernt

Redundante persönliche Einstellungen der App – alles läuft zentral über Souvera Central.
Direktverwendung von cURL im Backend – abgelöst durch den Nextcloud-eigenen HTTP-Client.

Sicherheit

Middleware sperrt sämtliche API-Endpunkte für Nutzer außerhalb der Gruppe souvera-users (HTTP 403).
PMG-API-Zugangsdaten werden mit Nextcloud-ICrypto verschlüsselt in der App-Config abgelegt und sind über die Oberfläche nicht auslesbar.
Vorschau rendert HTML in einer Sandbox-iframe; externe Ressourcen (Bilder, Skripte, Tracker) werden nicht geladen.
Virus-Quarantäne ist strikt schreibgeschützt – keine Freigabe- oder Download-Aktion möglich.

Bezugs-Handbücher: Souvera Shield – Anwenderhandbuch (Benutzer-Shelf) und Souvera Shield – Administratorhandbuch (Administratoren-Shelf).