Postfix 3.10: Updates, TLSRPT und der Weg zu 3.11

Postfix 3.10 richtig zeitlich einordnen

Zum Recherchezeitpunkt 20. Oktober 2026 ist Postfix 3.10 nicht der aktuelle stabile Entwicklungszweig: Diese Rolle hat Postfix 3.11. Der Hersteller führt 3.10 als Legacy-Zweig, versorgt ihn aber weiter mit Fehler- und Sicherheitskorrekturen. In den offiziellen Ankündigungen ist Postfix 3.10.14 vom 7. September 2026 als jüngster auffindbarer Patchstand dieses Zweigs genannt.

Diese Einordnung trennt zwei unterschiedliche Entscheidungen. Ein Wartungsupdate von etwa 3.10.8 auf einen neueren 3.10-Patch hält den gewählten Funktionszweig bei und übernimmt dessen Korrekturen. Ein Upgrade auf 3.11 wechselt dagegen den Entwicklungszweig und muss deshalb auf geänderte Funktionen, Konfigurationskompatibilität, Erweiterungen und Betriebsabläufe geprüft werden. Ein höherer Haupt- und Nebenzweig ist nicht automatisch die passende Maßnahme für jedes produktive System.

Prüfe bei Linux-Paketen zusätzlich zur sichtbaren Postfix-Version die Paketmetadaten, das Changelog und die Sicherheitshinweise des Betriebssystemanbieters. Kläre dort, welche Korrekturen dieses konkrete Paket enthält und ob der Anbieter Backports dokumentiert. Die Upstream-Ankündigung beschreibt dagegen den Postfix-Release und belegt keine allgemeine Backportpolitik einer Distribution.

Für die Wartungsplanung bedeutet das: Dokumentiere zunächst die installierte Paketversion, den Repository-Kanal und die lokalen Anpassungen. Vergleiche anschließend, welche Korrekturen der Anbieter des Betriebssystems für dieses Paket ausweist. Erst dieser Abgleich zeigt, ob ein ausstehendes Postfix-Update innerhalb von 3.10 erforderlich ist oder ob ein geplanter Wechsel auf 3.11 einen zusätzlichen fachlichen Nutzen hätte. Die Nummer 3.10.14 ist dabei ein Upstream-Referenzpunkt, keine Installationsanweisung für ein bestimmtes Linux-System.

MTA-Rolle, SMTP-Ports und Systemgrenzen

Postfix ist ein Mail Transfer Agent (MTA). Er nimmt E-Mails über SMTP an, entscheidet anhand seiner Routing- und Policy-Konfiguration über die weitere Verarbeitung und übergibt Nachrichten an andere Mailserver oder lokale Zustellpfade. Damit bildet Postfix die Transportebene eines Mailservers unter Linux. Seine Konfiguration bestimmt jedoch nicht automatisch, wie Nutzende ihre Postfächer lesen oder wie verdächtige Inhalte bewertet werden.

Ein IMAP- oder POP3-Server stellt Postfächer für Mailprogramme bereit und ist eine andere Komponente als der SMTP-Transport. Ebenso ersetzen Postfix-Funktionen keine vollständige Spam- oder Virenfilterlösung: Solche Systeme müssen bei Bedarf passend angebunden, gepflegt und überwacht werden. Diese Trennung ist praktisch relevant, weil ein erfolgreicher SMTP-Test weder den Abruf eines Postfachs noch die Qualität einer Inhaltsprüfung belegt.

Port 25 dient üblicherweise dem SMTP-Verkehr zwischen Mailservern und damit dem öffentlichen MX-Betrieb. Die Ports 587 und 465 sind dagegen für die Einlieferung durch Mailclients vorgesehen, meist mit Authentifizierung und einer eigenen Dienstdefinition. Postfix behandelt diese Rollen nicht nur organisatorisch unterschiedlich: Manche Einstellungen dürfen oder sollten gerade nicht pauschal für alle SMTP-Dienste gelten.

Vor Änderungen brauchst du administrative Rechte, ein wiederherstellbares Backup der Postfix-Konfiguration und ein Wartungsfenster, das zu Queue, Zustellfristen und angebundenen Anwendungen passt. Halte außerdem fest, ob der Server ausgehend versendet, als öffentlicher MX empfängt oder Client-Einlieferung anbietet. Diese Diensttrennung verhindert, dass eine für Submission sinnvolle Datenschutzentscheidung versehentlich den öffentlich erreichbaren Port 25 verändert.

TLSRPT ergänzt sichere Mailzustellung

Postfix 3.10 bietet optionale TLSRPT-Unterstützung im SMTP-Client. Domains können per DNS einen Empfänger für aggregierte TLS-Berichte veröffentlichen; RFC 8460 erlaubt E-Mail-Adressen und HTTPS-Endpunkte. Postfix meldet dabei nur Erfolg oder Fehlschlag von TLS-Handshakes, höchstens einen abschließenden Status je SMTP-Verbindung. Fehlgeschlagener Verbindungsaufbau und Abbrüche vor oder nach dem TLS-Handshake werden nicht erfasst.

Die Versionsnummer 3.10 allein belegt jedoch nicht, dass ein installiertes Postfix-Paket TLSRPT tatsächlich nutzen kann. Die Funktion setzt voraus, dass Postfix mit einer unterstützenden TLSRPT-Clientbibliothek und der Build-Option USE_TLSRPT erstellt wurde. Vor der Konfigurationsplanung musst du deshalb anhand der Paketdokumentation, der ausgewiesenen Build-Merkmale und verfügbarer Zusatzpakete prüfen, ob deine Distribution diese Unterstützung eingebaut hat.

TLSRPT ergänzt Verfahren, die den TLS-Schutz einer Zustellung tatsächlich beeinflussen. STARTTLS ermöglicht die Aushandlung einer Transportverschlüsselung. DANE nutzt TLSA-Einträge und setzt für seine Sicherheitsannahmen DNSSEC voraus; MTA-STS veröffentlicht eine Policy für erwartete TLS-Eigenschaften. Scheitert eine verbindlich geltende DANE- oder MTA-STS-Vorgabe, kann TLSRPT nachgelagerte Hinweise über solche Fehler liefern. Es aktiviert aber weder Verschlüsselung noch Zertifikatsprüfung selbst.

Dabei sind zwei Rollen zu unterscheiden. Die empfangende Domain veröffentlicht einen rua-Endpunkt und betreibt oder beauftragt dessen überwachten Empfang sowie die Auswertung eingehender Berichte. Ein berichtender MTA benötigt dagegen ein passend gebautes und aktiviertes Postfix sowie eine separate Infrastruktur, die Ereignisse sammelt, abruft, aggregiert und Reports versendet. Diese beiden Perspektiven können organisatorisch getrennt sein; ein veröffentlichender Domaininhaber muss nicht auf demselben System selbst TLSRPT-Berichte erzeugen.

Ein TLS-Policy-Plugin gehört deshalb nicht allgemein zu jeder TLSRPT-Berichtskette. Postfix unterstützt DANE selbst. Ein geeignetes Plugin wird insbesondere dann zusätzlich relevant, wenn der sendende MTA MTA-STS-Policyinformationen über smtp_tls_policy_maps einbindet. Postfix 3.10 erweitert die Antworten eines solchen Plugins um TLSRPT-bezogene Attribute; daraus folgt jedoch weder, dass jede Installation ein Plugin benötigt, noch dass TLSRPT in jedem 3.10-Paket eingebaut ist.

TLSRPT ist außerdem kein Echtzeitmonitoring. Die Postfix-Anleitung nennt im Durchschnitt etwa zwölf Stunden bis zum Eintreffen einer Fehlermeldung und grenzt Reports daher ausdrücklich von akuter Störungsüberwachung ab. Für laufende Zustellprobleme bleiben Queue-Prüfung, Logauswertung und Alarmierung notwendig. TLSRPT hilft vor allem, wiederkehrende Muster und Policy-Probleme über viele Zustellversuche hinweg sichtbar zu machen.

Postfix-Update im 3.10-Zweig vorbereiten

Ein Update innerhalb von Postfix 3.10 ist eine Wartungsaufgabe mit klarer Ausgangslage: Du aktualisierst einen bestehenden Legacy-Zweig auf den von deiner Distribution bereitgestellten Patchstand. Sichere vor dem Eingriff die Postfix-Konfiguration und plane ein Wartungsfenster. Prüfe außerdem, ob der Server ausgehende Zustellungen, MX-Verkehr oder Submission bereitstellt, denn davon hängen Kontrolle und Rückfallplanung ab.

Ermittle zuerst die installierte beziehungsweise mit dem aufgerufenen Programm abgefragte Postfix-Version und dokumentiere die explizit in main.cf gesetzten Parameter. Die ersten beiden Befehle dienen der lesenden Bestandsaufnahme. postfix check ist dagegen ein administrativer Wartungsbefehl: Er kontrolliert insbesondere Besitz- und Zugriffsrechte von Dateien und Verzeichnissen und kann fehlende Verzeichnisse anlegen. Führe ihn deshalb mit den vorgesehenen administrativen Rechten und nicht unter der Annahme eines garantiert unveränderten Dateisystems aus.

postconf mail_version
postconf -n
postfix check

Die Ausgabe von postconf mail_version benennt die Version der aufgerufenen Postfix-Programmbasis. postconf -n zeigt Parameter mit expliziten name=value-Einträgen in main.cf. Dazu können auch Einstellungen gehören, deren Wert dem aktuellen eingebauten Standard entspricht; die Ausgabe ist daher kein sicherer Nachweis einer tatsächlichen Abweichung vom Default. Nach einem Versionswechsel können sich außerdem Standardwerte ändern, während ein zuvor gesetzter Eintrag bestehen bleibt.

また postfix check ist keine vollständige Validierung der Mailserver-Konfiguration. Der Befehl kann Probleme mit Verzeichnis- oder Dateirechten melden und fehlende Verzeichnisse erzeugen, beurteilt aber nicht umfassend die fachliche Richtigkeit aller Parameter. Zertifikatsketten, externe Maps, DNS-Abhängigkeiten, Filter, Authentifizierung und die Integration angebundener Dienste müssen separat geprüft werden.

Verwende für das Paketupdate den unterstützten Aktualisierungsweg deiner Distribution. Prüfe in deren Paketmetadaten, Changelog und Sicherheitshinweisen, welche Korrekturen und etwaigen Backports das konkrete Paket ausweist. Vergleiche diese Angaben mit den Upstream-Ankündigungen. Leite aus einer verkürzten Versionszeichenfolge allein keinen fehlenden Patch ab.

Die besondere, von Postfix dokumentierte Pflicht zur Prozessaktualisierung betrifft das Upgrade von einem älteren Entwicklungszweig auf Postfix 3.10.0. Wegen einer Änderung des internen Zustellagentenprotokolls ist danach mindestens postfix reload oder ein Stop mit anschließendem Start erforderlich; andernfalls können Zustellagenten vor einem unerwarteten smtputf8-Attribut warnen. Diese Begründung lässt sich nicht pauschal auf jedes spätere Patchupdate innerhalb von 3.10 übertragen.

Bei Wartungsupdates innerhalb des 3.10-Zweigs prüfst du stattdessen, ob das Paketwerkzeug den Dienst bereits distributionsgemäß neu geladen oder gestartet hat und ob die laufenden Prozesse zum aktualisierten Stand gehören. Ist das nicht der Fall, verwendest du den von Distribution und Paket vorgesehenen Reload oder Neustart. Kontrolliere anschließend Warteschlange und Logs im Wartungsfenster, statt einen bestimmten Aktivierungsbefehl unabhängig vom Paketverhalten vorauszusetzen.

TLSRPT mit DNS und Berichtsinfrastruktur planen

Bei TLSRPT müssen die Rolle der berichtsempfangenden Domain und die Rolle eines berichtenden MTAs getrennt geplant werden. Eine Domain, die Berichte über Zustellungen an ihre eigene Infrastruktur erhalten möchte, veröffentlicht einen rua-Endpunkt im DNS und stellt sicher, dass dessen Empfang, Schutz, Speicherung und Auswertung verbindlich betreut werden. Der TXT-Record beschreibt damit, wohin andere sendende MTAs ihre aggregierten Berichte adressieren sollen.

Ein MTA, der selbst TLSRPT-Berichte erzeugen soll, benötigt unabhängig davon ein Postfix-Paket, das mit einer TLSRPT-Clientbibliothek und USE_TLSRPT gebaut wurde. Die Angabe Postfix 3.10 bestätigt nur, ab welchem Zweig die Integration verfügbar ist; sie weist das Build-Merkmal eines konkreten Binärpakets nicht nach. Prüfe daher Paketdokumentation, Build-Informationen und verfügbare Zusatzpakete deiner Distribution, bevor du die Funktion einplanst.

Auf jedem beteiligten Postfix-System nimmt ein lokaler コレクター die von der eingebundenen TLSRPT-Bibliothek über einen lokalen Unix-Domain-Socket übergebenen Ereignisse entgegen. Davon getrennt können Fetcher, zentrale Aggregation und Reportgenerator betrieben werden: Sie holen die gesammelten Daten ab, erstellen die vorgesehenen Zusammenfassungen und versenden Reports an die von Empfängerdomains veröffentlichten Ziele. Diese nachgelagerten Komponenten können auf anderen Systemen zentralisiert sein; der lokale Collector am jeweiligen Postfix-System lässt sich dadurch nicht ersetzen.

A Policy-Plugin ist nur für bestimmte senderseitige Szenarien zusätzlich erforderlich. Nutzt der MTA MTA-STS-Policyinformationen über smtp_tls_policy_maps, muss das dafür eingesetzte Plugin die TLSRPT-bezogenen Attribute unterstützen. DANE wird von Postfix selbst unterstützt. Weder der DNS-Eintrag einer empfangenden Domain noch die Berichtsverarbeitung eines passend gebauten MTA setzt deshalb pauschal ein MTA-STS-Plugin voraus.

Der folgende Eintrag erläutert ausschließlich die DNS-Syntax für einen Berichtsempfänger. example.invalid ist absichtlich keine produktive Domain und darf nicht unverändert übernommen werden. Das Tag v=TLSRPTv1 kennzeichnet das Verfahren; rua benennt hier ein Ziel für Berichte. RFC 8460 erlaubt neben E-Mail auch HTTPS-Endpunkte.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Für TLSRPT-Berichte beschreibt Postfix 3.10 den Header TLS-Required: no, damit der Bericht bei der Übermittlung auf das TLS-Sicherheitsniveau „may“ zurückfallen kann. Diese eng begrenzte Ausnahme verhindert, dass ein Fehlerbericht selbst an einer strikten TLS-Vorgabe scheitert. Sie ist keine Anweisung, die TLS-Anforderungen für reguläre Geschäfts- oder Nutzermails abzusenken.

Submission schützen, TLS-Optionen gezielt bewerten

セッティング smtpd_hide_client_session richtet sich an die authentifizierte Mailclient-Einlieferung. Ist sie aktiviert, erzeugt der SMTP-Server Received:-Header ohne Informationen aus der Client-Sitzung. Je nach Sitzung können damit etwa Client-Hostname und -IP-Adresse, TLS-Sitzungsdaten, SASL-Logininformationen sowie SMTP-Protokolldetails aus dem Header ausgeblendet werden.

Ordne diese Datenschutzfunktion einer dedizierten Submission-Service-Definition für Port 587 oder 465 zu, statt sie pauschal global in main.cf zu aktivieren. Der öffentliche Port-25-MTA hat eine andere Rolle im Server-zu-Server-Transport. Die Postfix-Dokumentation verlangt dort den Standardwert, damit Anforderungen aus RFC 5321 erfüllt bleiben.

Die Entscheidung betrifft somit nicht nur Privatsphäre, sondern auch Nachvollziehbarkeit und Dienstgrenzen. Für authentifizierte Clients kann die Verringerung unnötiger Metadaten angemessen sein. Auf einem öffentlichen MX würde dieselbe Einstellung jedoch die dokumentierte Erwartung an Received:-Informationen verletzen. Prüfe deshalb getrennte Dienste, Listener und ihre jeweiligen Parameter statt einer einheitlichen Globalregel.

Postfix 3.10.0 enthält außerdem eine Anpassung für OpenSSL 3.5 und dessen Gruppen-Syntax für Post-Quantum-Kryptografie. Soll die Gruppenauswahl bewusst vollständig an die zentral gepflegte OpenSSL-Konfiguration delegiert werden, müssen tls_eecdh_auto_curves そして tls_ffdhe_auto_groups beide leer gesetzt sein. Erst diese gemeinsame Einstellung überlässt OpenSSL die Auswahl; Postfix bildet die neue OpenSSL-Syntax nicht selbst nach.

Das Leeren beider automatischen Parameter ist ein Spezialfall für zentral gepflegte Kryptovorgaben, keine allgemeine Härtungsempfehlung. Geeignet ist es nur, wenn die wirksame OpenSSL-Konfiguration bekannt, versioniert und getestet ist. Fehlt diese Kontrolle, kann die Verlagerung der Auswahl Fehlkonfigurationen verdecken oder unerwartete TLS-Eigenschaften erzeugen; dann bleiben die expliziten Postfix-Vorgaben nachvollziehbarer.

Patchstände und bekannte Fehlerbilder prüfen

Die Versionsangabe 3.10 allein beschreibt keinen einheitlichen technischen Stand. Entscheidend sind die konkrete Patchversion, die Changelog-Angaben des Distributionspakets und gegebenenfalls zurückportierte Korrekturen. Postfix 3.10.14 wurde am 7. September 2026 als Legacy-Ausgabe zusammen mit weiteren gepflegten Zweigen angekündigt. Daraus folgt nicht, dass jedes Linux-Paket bereits diesen Upstream-Stand enthält.

Ein konkretes Beispiel ist Postfix 3.10.6: Diese Ausgabe korrigierte ein Problem rund um TLS-Required: no und clientseitigen TLS-Wrappermode. Die frühere Umsetzung konnte solche Verbindungen beeinträchtigen; die Korrektur behandelt sie mit dem Sicherheitsniveau encrypt. Wer SMTPS-Wrappermode verwendet, sollte daher Patchstände und den tatsächlich eingesetzten Übertragungsweg prüfen, statt aus „3.10“ auf gleiches Verhalten zu schließen.

Die Ankündigung zu 3.10.14 nennt unter anderem Korrekturen und Härtungen für eine SMTP-Smuggling-Konstellation mit smtpd_proxy_filter. Das ist keine pauschale Aussage, dass jeder Mailserver betroffen ist: Der Parameter ist standardmäßig deaktiviert, und die Relevanz hängt von der lokalen Konfiguration sowie der vorgeschalteten oder angebundenen Filterarchitektur ab. Prüfe deshalb zuerst, ob diese Funktion überhaupt aktiv genutzt wird.

Bei auffälliger Zustellung hat die Fehlersuche eine sinnvolle Reihenfolge: Zuerst kontrollierst du wirksame Abweichungen und die Konfigurationsvalidierung, dann den erfolgten Reload nach einem Upgrade. Danach untersuchst du Warteschlange und Protokolle auf wiederkehrende TLS-, Verbindungs- oder Deferred-Meldungen. Eine systematische Anleitung zur Analyse von Postfix-Logs hilft dabei, einzelne Ereignisse einer Queue-ID und ihrem Zustellversuch zuzuordnen.

警告： Ein Versionswechsel ersetzt keine Ursachenanalyse. Ein Reload behebt weder ungültige Zertifikatsketten noch DNS-Fehler oder unpassende Routing-Regeln. Umgekehrt können fehlende Reloads nach einem Upgrade geänderte Prozesse oder Konfigurationen im Betrieb verdecken. Dokumentiere daher Patchstand, Paketquelle, Zeitpunkt der Aktivierung und beobachtete Logmeldungen gemeinsam.

TLSRPT-Berichte korrekt im Betrieb bewerten

TLSRPT-Berichte sind zeitverzögert und ersetzen kein Echtzeitmonitoring. Die Postfix-Dokumentation nennt durchschnittlich etwa zwölf Stunden bis zum Eintreffen eines Fehlerberichts. Bei Postfix beziehen sich die erfassten Ergebnisse auf TLS-Handshakes; Verbindungsaufbaufehler und Abbrüche vor oder nach dem Handshake fehlen. Für akute Vorfälle bleiben Queue-Monitoring, Logauswertung und Alarmierung erforderlich.

Auch Wiederverwendung begrenzt die Zählung: Eine wiederverwendete SMTP-Verbindung erzeugt keinen weiteren TLS-Handshake. Bei wiederaufgenommenen TLS-Sitzungen überspringt Postfix 3.10 die Erfassung standardmäßig; dafür ist smtp_tlsrpt_skip_reused_handshakes maßgeblich. Berichtsaggregate sind deshalb weder eine vollständige Anzahl aller SMTP-Verbindungen noch eine Nachrichten- oder Zustellquote. Bewerte Fehlerarten, Empfängerdomains, Zeiträume und wiederkehrende Muster zusammen mit den Serverprotokollen.

Die technische Zustellung eines Berichts schafft noch keinen Nutzen. Lege vorab fest, wer den rua-Empfänger betreut, wer Reports entgegennimmt und speichert und wie lange die Daten aufbewahrt werden. Da Berichte Informationen zu TLS-Sitzungen enthalten können, gehören Zugriffsrechte, Datenschutzvorgaben und ein Verfahren zur Löschung in das Betriebskonzept. Auch eine Eskalationsregel für wiederholte Fehler sollte vorhanden sein.

Die Auswertung verbindet daher zwei Ebenen: TLSRPT zeigt verdichtete Trends über einen Zeitraum, während Mailserver-Protokolle den konkreten Verlauf einzelner Zustellversuche liefern. Für die laufende Beobachtung ergänzt der Praxisleitfaden zur Postfix-Logüberwachung die Berichte um Methoden zur Einordnung von Fehlermeldungen und Warteschlangen. Automatische Alarme sollten auf zeitnahe Betriebsdaten reagieren, nicht erst auf eingegangene TLSRPT-Aggregate.

Wenn kein verantwortlicher Empfänger, keine geschützte Ablage und keine regelmäßige Auswertung vorgesehen sind, sollte die TLSRPT-Veröffentlichung zunächst geplant statt vorschnell aktiviert werden. Berichtsverantwortung ist Teil der Sicherheitsfunktion: Erst die Zuordnung eines Fehlers zu einer zuständigen Stelle ermöglicht eine nachvollziehbare Reaktion, etwa auf eine abgelaufene MTA-STS-Policy oder Probleme mit TLSA-Daten.

3.10 pflegen oder auf 3.11 wechseln

Die Wahl zwischen Patchpflege und Branchwechsel richtet sich nach Ausgangslage und Betriebsziel. Postfix 3.10 ist zum Recherchezeitpunkt ein weiterhin versorgter Legacy-Zweig, während 3.11 der stabile Entwicklungszweig ist. Regelmäßige Korrekturen innerhalb von 3.10 sind deshalb für bestehende Installationen sinnvoll; sie sind jedoch nicht mit einem Funktionsupgrade auf 3.11 gleichzusetzen.

Ein Wechsel auf 3.11 ist vor allem dann sachlich begründet, wenn dessen Funktionen oder der langfristige Zielstand benötigt werden. REQUIRETLS und JSON-Ausgaben bestimmter Verwaltungswerkzeuge sind als Merkmale des neueren Zweigs dokumentiert und dürfen nicht als Postfix-3.10-Features eingeplant werden. Vor einem Branchwechsel sind Konfigurationsparameter, angebundene Filter, Authentifizierung und Automatisierung auf Kompatibilität zu prüfen.

Für ein stabiles 3.10-System ohne neuen Funktionsbedarf ist kontinuierliche Patchpflege die unmittelbar passende Maßnahme. Sie verlangt dennoch einen kontrollierten Ablauf mit Backup, Paketprüfung, Validierung, Prüfung der Prozessaktivierung und Beobachtung. Ein Branchwechsel braucht dagegen einen fachlichen Anlass und ein geplantes Wartungsfenster; allein die höhere Versionsnummer ist kein ausreichendes Entscheidungskriterium.