Postfix 3.10: Opdateringer, TLSRPT og vejen mod 3.11

At placere Postfix 3.10 i den rigtige tidsmæssige sammenhæng

På undersøgelsestidspunktet den 20. oktober 2026 er Postfix 3.10 ikke den aktuelle stabile udviklingsgren: Den rolle indtager Postfix 3.11. Producenten angiver 3.10 som Legacy-gren, men leverer fortsat fejlrettelser og sikkerhedsopdateringer til den. I de officielle meddelelser nævnes Postfix 3.10.14 fra den 7. september 2026 som den seneste tilgængelige opdatering i denne gren.

Denne inddeling adskiller to forskellige beslutninger. En vedligeholdelsesopdatering fra f.eks. 3.10.8 til en nyere 3.10-patch bevarer den valgte funktionsgren og overtager dens rettelser. En opgradering til 3.11 skifter derimod udviklingsgren og skal derfor kontrolleres med hensyn til ændrede funktioner, konfigurationskompatibilitet, udvidelser og driftsprocesser. En højere hoved- og undergren er ikke automatisk den rette foranstaltning for ethvert produktivt system.

For Linux-pakker skal du ud over den synlige Postfix-version også tjekke pakkemetadataene, changeloggen og sikkerhedsmeddelelserne fra operativsystemudbyderen. Find ud af, hvilke rettelser denne konkrete pakke indeholder, og om udbyderen dokumenterer backports. Upstream-meddelelsen beskriver derimod Postfix-udgivelsen og er ikke et bevis på en distributions generelle backport-politik.

For vedligeholdelsesplanlægningen betyder det: Dokumentér først den installerede pakkeversion, repository-kanalen og de lokale tilpasninger. Sammenlign derefter, hvilke rettelser operativsystemudbyderen angiver for denne pakke. Først denne sammenligning viser, om der er en udestående Postfix-opdatering om det er nødvendigt inden version 3.10, eller om en planlagt overgang til 3.11 ville give en yderligere faglig fordel. Punkt 3.10.14 er i denne sammenhæng et referencepunkt for udviklingen, ikke en installationsvejledning til et bestemt Linux-system.

MTA-rolle, SMTP-porte og systembegrænsninger

Postfix er et Mail Transfer Agent (MTA). Den modtager e-mails via SMTP, beslutter på baggrund af sin routing- og politikkonfiguration, hvordan de skal behandles videre, og videresender meddelelser til andre mailservere eller lokale leveringsstier. Dermed udgør Postfix transportlaget i en mailserver under Linux. Dens konfiguration bestemmer dog ikke automatisk, hvordan brugerne læser deres postkasser, eller hvordan mistænkeligt indhold vurderes.

En IMAP- eller POP3-server stiller postkasser til rådighed for e-mail-programmer og er en anden komponent end SMTP-transporten. Ligeledes erstatter Postfix-funktioner ikke en komplet spam- eller virusfilterløsning: Sådanne systemer skal om nødvendigt integreres, vedligeholdes og overvåges på passende vis. Denne adskillelse er af praktisk betydning, da en vellykket SMTP-test hverken beviser, at en postkasse kan hentes, eller at indholdskontrollen er af tilstrækkelig kvalitet.

Port 25 bruges normalt til SMTP-trafik mellem mailservere og dermed til den offentlige MX-drift. Portene 587 og 465 er derimod beregnet til indsendelse fra e-mail-klienter, oftest med autentificering og en egen tjenestedefinition. Postfix behandler disse roller ikke kun organisatorisk forskelligt: Nogle indstillinger må eller bør netop ikke gælde generelt for alle SMTP-tjenester.

Inden du foretager ændringer, skal du have administratorrettigheder, en sikkerhedskopi af Postfix-konfigurationen, der kan gendannes, samt et vedligeholdelsesvindue, der passer til køen, leveringsfristerne og de tilknyttede applikationer. Notér desuden, om serveren sender udgående e-mails, modtager som offentlig MX-server eller tilbyder klientindlevering. Disse Afskedigelse forhindrer, at en databeskyttelsesbeslutning, der er relevant for indsendelse, ved en fejltagelse ændrer den offentligt tilgængelige port 25.

TLSRPT supplerer sikker e-mail-levering

Postfix 3.10 tilbyder valgfri TLSRPT-understøttelse i SMTP-klienten. Domæner kan via DNS offentliggøre en modtager for aggregerede TLS-rapporter; RFC 8460 tillader e-mail-adresser og HTTPS-endepunkter. Postfix rapporterer i den forbindelse kun, om TLS-håndtryk er lykkedes eller mislykkedes, højst én afsluttende status pr. SMTP-forbindelse. Mislykkede forbindelsesoprettelser og afbrydelser før eller efter TLS-håndtrykket registreres ikke.

Versionsnummeret 3.10 er dog ikke i sig selv bevis for, at en installeret Postfix-pakke rent faktisk kan bruge TLSRPT. Funktionen forudsætter, at Postfix er udstyret med et TLSRPT-klientbibliotek, der understøtter funktionen, samt build-indstillingen USE_TLSRPT er blevet oprettet. Inden du går i gang med konfigurationsplanlægningen, skal du derfor på baggrund af pakkedokumentationen, de angivne build-egenskaber og tilgængelige tillægspakker kontrollere, om din distribution har denne understøttelse indbygget.

TLSRPT supplerer procedurer, der reelt påvirker TLS-beskyttelsen af en levering. STARTTLS muliggør forhandling af en transportkryptering. DANE anvender TLSA-poster og forudsætter DNSSEC for sine sikkerhedsantagelser; MTA-STS offentliggør en politik for forventede TLS-egenskaber. Hvis et bindende DANE- eller MTA-STS-krav mislykkes, kan TLSRPT levere efterfølgende meddelelser om sådanne fejl. Det aktiverer dog hverken kryptering eller certifikatvalidering i sig selv.

Her skal der skelnes mellem to roller. Det modtagende domæne offentliggør en rua-endepunkt og varetager eller sørger for, at modtagelsen overvåges, samt at indkommende rapporter analyseres. En rapporterende MTA har derimod brug for en korrekt konfigureret og aktiveret Postfix samt en separat infrastruktur, der indsamler, henter, aggregerer og sender rapporter. Disse to perspektiver kan være organisatorisk adskilt; en domæneejer, der offentliggør rapporter, behøver ikke selv at generere TLSRPT-rapporter på det samme system.

Et TLS-policy-plugin indgår derfor ikke generelt i alle TLSRPT-rapporteringskæder. Postfix understøtter selv DANE. Et passende plugin bliver især relevant, når den afsendende MTA sender MTA-STS-policyoplysninger via smtp_tls_policy_maps integrerer. Postfix 3.10 udvider svarene fra et sådant plugin med TLSRPT-relaterede attributter; det betyder dog hverken, at hver installation kræver et plugin, eller at TLSRPT er indbygget i alle 3.10-pakker.

TLSRPT er desuden ikke en overvågning i realtid. Postfix-vejledningen angiver, at der i gennemsnit går omkring tolv timer, før en fejlmeddelelse modtages, og adskiller derfor udtrykkeligt rapporter fra overvågning af akutte fejl. Ved løbende leveringsproblemer er det stadig nødvendigt at kontrollere køen, analysere logfilerne og udløse alarmer. TLSRPT hjælper først og fremmest med at synliggøre tilbagevendende mønstre og problemer med politikker på tværs af mange leveringsforsøg.

Forberedelse af Postfix-opdatering i 3.10-grenen

En opdatering inden for Postfix 3.10 er en vedligeholdelsesopgave med en klar udgangssituation: Du opdaterer en eksisterende legacy-gren til den patch-status, som din distribution stiller til rådighed. Sikkerhedskopier Postfix-konfigurationen inden indgrebet, og planlæg et vedligeholdelsesvindue. Kontroller desuden, om serveren håndterer udgående leveringer, MX-trafik eller Submission, da kontrol og beredskabsplanlægning afhænger heraf.

Find først ud af, hvilken Postfix-version der er installeret, eller hvilken version der er angivet af det åbnede program, og dokumentér dette eksplicit i main.cf de indstillede parametre. De to første kommandoer bruges til at foretage en læsende statusopgørelse. postfix check er derimod en administrativ vedligeholdelseskommando: Den kontrollerer især ejerskabs- og adgangsrettigheder til filer og mapper og kan oprette manglende mapper. Kør den derfor med de tilsigtede administratorrettigheder og ikke under den forudsætning, at filsystemet er garanteret uændret.

postconf mail_version
postconf -n
postfix check

Udgivelsen af postconf mail_version angiver versionen af det Postfix-program, der er startet. postconf -n viser parametre med eksplicitte name=value-poster i main.cf. Dette kan også omfatte indstillinger, hvis værdi svarer til den aktuelt indstillede standard; udskriften er derfor ikke et sikkert bevis på en faktisk afvigelse fra standardindstillingen. Efter en versionsopdatering kan standardværdierne desuden ændre sig, mens en tidligere indstillet værdi forbliver uændret.

Også postfix check er ikke en fuldstændig validering af mailserverkonfigurationen. Kommandoen kan rapportere problemer med mappe- eller filrettigheder og oprette manglende mapper, men foretager ikke en omfattende vurdering af den faglige korrekthed af alle parametre. Certifikatkæder, eksterne kort, DNS-afhængigheder, filtre, autentificering og integrationen af tilknyttede tjenester skal kontrolleres separat.

Brug den understøttede opdateringsmetode for din distribution til at opdatere pakken. Tjek pakkens metadata, changelog og sikkerhedsmeddelelser for at se, hvilke rettelser og eventuelle backports den pågældende pakke indeholder. Sammenlign disse oplysninger med meddelelserne fra upstream. Konkluder ikke, at der mangler en patch, alene på baggrund af en forkortet versionsstreng.

Den særlige forpligtelse til at opdatere processen, som er beskrevet i Postfix-dokumentationen, vedrører opgraderingen fra en ældre udviklingsgren til Postfix 3.10.0. På grund af en ændring i det interne leveringsagentprotokol skal der herefter mindst postfix reload eller et stop efterfulgt af en start er påkrævet; ellers kan budene blive udsat for en uventet smtputf8-attributten »advarsel«. Denne begrundelse kan ikke generelt overføres til alle senere patch-opdateringer inden for version 3.10.

Ved vedligeholdelsesopdateringer inden for 3.10-grenen skal du i stedet kontrollere, om pakkeværktøjet allerede har genindlæst eller genstartet tjenesten i overensstemmelse med distributionen, og om de kørende processer hører til den opdaterede version. Er dette ikke tilfældet, skal du bruge den genindlæsning eller genstart, der er forudset af distributionen og pakken. Kontroller derefter køen og logfilerne i vedligeholdelsesvinduet, i stedet for at forudsætte en bestemt aktiveringskommando uafhængigt af pakkens adfærd.

Planlægning af TLSRPT med DNS og rapporteringsinfrastruktur

I TLSRPT skal rollen som det domæne, der modtager rapporter, og rollen som en rapporterende MTA planlægges separat. Et domæne, der ønsker at modtage rapporter om leveringer til sin egen infrastruktur, offentliggør en rua-endepunkt i DNS og sikrer, at modtagelse, beskyttelse, lagring og analyse heraf varetages på en forpligtende måde. TXT-posten beskriver dermed, hvor andre afsende-MTA’er skal sende deres samlede rapporter hen.

En MTA, der selv skal generere TLSRPT-rapporter, har uanset hvad brug for et Postfix-pakke, der indeholder et TLSRPT-klientbibliotek og USE_TLSRPT blev bygget. Angivelsen »Postfix 3.10« bekræfter blot, fra hvilken gren integrationen er tilgængelig; den angiver ikke build-kendetegnet for en konkret binærpakke. Tjek derfor pakkedokumentationen, build-oplysningerne og de tilgængelige tillægspakker i din distribution, inden du planlægger at bruge funktionen.

På hvert deltagende Postfix-system kører en lokal Collector de begivenheder, der overføres fra det integrerede TLSRPT-bibliotek via en lokal Unix-domæne-socket. Uafhængigt heraf kan Fetcher, den centrale aggregering og rapportgeneratoren køre: De henter de indsamlede data, udarbejder de forudbestemte oversigter og sender rapporter til de destinationer, der er offentliggjort af modtagerdomænerne. Disse efterfølgende komponenter kan være centraliseret på andre systemer; den lokale Collector på det pågældende Postfix-system kan dog ikke erstattes herved.

En Policy-plugin er kun yderligere påkrævet i visse scenarier på afsenderens side. Hvis MTA’en anvender MTA-STS-politikoplysninger via smtp_tls_policy_maps, skal det anvendte plugin understøtte de TLSRPT-relaterede attributter. DANE understøttes af Postfix selv. Hverken DNS-posten for et modtagende domæne eller rapportbehandlingen i en korrekt opbygget MTA forudsætter derfor generelt et MTA-STS-plugin.

Følgende opslag beskriver udelukkende DNS-syntaksen for en rapportmodtager. example.invalid er bevidst ikke et produktivt domæne og må ikke overtages uændret. Tagget v=TLSRPTv1 karakteriserer fremgangsmåden; rua angiver her en destination for rapporter. RFC 8460 tillader ud over e-mail også HTTPS-endepunkter.

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

For TLSRPT-rapporter definerer Postfix 3.10 overskriften TLS-Required: no, så rapporten kan falde tilbage til TLS-sikkerhedsniveauet „may“ ved overførslen. Denne snævert afgrænsede undtagelse forhindrer, at en fejlrapport selv strander på grund af en streng TLS-krav. Den er ikke en anvisning om at sænke TLS-kravene for almindelige forretnings- eller bruger-e-mails.

Beskyttelse af indsendelser, målrettet vurdering af TLS-indstillinger

Indstillingen smtpd_hide_client_session Gælder for autentificeret indsendelse fra e-mail-klienter. Hvis denne funktion er aktiveret, genererer SMTP-serveren »Received:«-headere uden oplysninger fra klientens session. Afhængigt af sessionen kan dette f.eks. medføre, at klientens værtsnavn og IP-adresse, TLS-sessionsdata, SASL-loginoplysninger samt SMTP-logdetaljer fjernes fra headeren.

Sorter disse Databeskyttelsesfunktion en dedikeret definition af indsendelsestjenesten for port 587 eller 465, i stedet for at definere den generelt globalt i main.cf skal aktiveres. Den offentlige MTA på port 25 har en anden rolle i server-til-server-overførslen. Postfix-dokumentationen kræver, at standardværdien anvendes her, så kravene i RFC 5321 fortsat opfyldes.

Beslutningen vedrører således ikke kun privatlivets fred, men også sporbarhed og tjenestegrænser. For godkendte klienter kan det være hensigtsmæssigt at reducere unødvendige metadata. På en offentlig MX-server ville den samme indstilling imidlertid stride mod den dokumenterede forventning til »Received:«-oplysninger. Overvej derfor at anvende separate tjenester, lyttere og deres respektive parametre i stedet for en ensartet global regel.

Postfix 3.10.0 indeholder desuden en tilpasning til OpenSSL 3.5 og dets gruppesyntaks til post-quantum-kryptografi. Hvis man bevidst ønsker at delegere valg af grupper fuldstændigt til den centralt vedligeholdte OpenSSL-konfiguration, skal tls_eecdh_auto_curves og tls_ffdhe_auto_groups Begge skal være tomme. Først når denne fælles indstilling er angivet, overlader OpenSSL valget til Postfix; Postfix efterligner ikke selv den nye OpenSSL-syntaks.

Nulstilling af begge automatiske parametre er en Særligt tilfælde til centralt vedligeholdte krypteringsindstillinger, ikke en generel anbefaling om sikkerhedsforstærkning. Dette er kun hensigtsmæssigt, hvis den faktiske OpenSSL-konfiguration er kendt, versioneret og testet. Mangler denne kontrol, kan flytningen af valget skjule fejlkonfigurationer eller skabe uventede TLS-egenskaber; i så fald forbliver de eksplicitte Postfix-indstillinger mere gennemsigtige.

Kontroller patch-status og kendte fejl

Versionsangivelsen 3.10 i sig selv beskriver ikke et ensartet teknisk niveau. Det afgørende er den konkrete patchversion, oplysningerne i changeloggen for distributionspakken og eventuelt tilbageporterede rettelser. Postfix 3.10.14 blev den 7. september 2026 annonceret som en legacy-udgave sammen med andre vedligeholdte grene. Det betyder dog ikke, at alle Linux-pakker allerede indeholder denne upstream-status.

Et konkret eksempel er Postfix 3.10.6: Denne udgave rettede et problem vedrørende TLS påkrævet: nej og TLS-wrapper-tilstand på klientsiden. Den tidligere implementering kunne forringe sådanne forbindelser; rettelsen behandler dem med sikkerhedsniveauet „encrypt“. Hvis man bruger SMTPS-wrapper-tilstand, bør man derfor kontrollere patch-status og den faktisk anvendte overførselsvej i stedet for at konkludere, at der er tale om samme adfærd som i »3.10«.

Meddelelsen fra 3.10.14 nævner blandt andet rettelser og sikkerhedsforbedringer vedrørende en SMTP-smuggling-konstellation med smtpd_proxy_filter. Dette er ikke en generel påstand om, at alle mailservere er berørt: Parameteren er som standard deaktiveret, og relevansen afhænger af den lokale konfiguration samt den forudgående eller tilknyttede filterarkitektur. Kontroller derfor først, om denne funktion overhovedet er aktiv.

Ved unormal levering er der en fornuftig rækkefølge for fejlfinding: Først kontrollerer du faktiske afvigelser og konfigurationsvalideringen, derefter om genindlæsningen er gennemført efter en opgradering. Derefter undersøger du køen og logfilerne for tilbagevendende TLS-, forbindelses- eller Deferred-meddelelser. En systematisk vejledning til Analyse af Postfix-logfiler hjælper med at knytte enkelte hændelser til et kø-ID og det tilhørende leveringsforsøg.

Advarsel: En versionsopdatering er ikke det samme som en årsagsanalyse. En genindlæsning løser hverken ugyldige certifikatkæder, DNS-fejl eller forkerte routingregler. Omvendt kan manglende genindlæsninger efter en opgradering skjule ændrede processer eller konfigurationer i driften. Dokumentér derfor samlet patchstatus, pakkekilde, tidspunkt for aktivering og observerede logmeddelelser.

Korrekt vurdering af TLSRPT-rapporter i driften

TLSRPT-rapporter er forsinkede og kan ikke erstatte overvågning i realtid. Ifølge Postfix-dokumentationen går der i gennemsnit omkring tolv timer, før en fejlrapport modtages. I Postfix vedrører de registrerede resultater TLS-handshakes; fejl ved oprettelse af forbindelser og afbrydelser før eller efter handshaken mangler. Ved akutte hændelser er køovervågning, loganalyse og alarmering fortsat nødvendigt.

Også genbrug begrænser tællingen: En genbrugt SMTP-forbindelse genererer ikke et nyt TLS-håndtryk. Ved genoptagede TLS-sessioner springer Postfix 3.10 som standard over registreringen; her er smtp_tlsrpt_skip_reused_handshakes afgørende. Rapporteringsaggregater er derfor hverken et fuldstændigt antal af alle SMTP-forbindelser eller en besked- eller leveringsprocent. Vurder fejltyper, modtagerdomæner, tidsperioder og tilbagevendende mønstre sammen med serverlogfilerne.

Den tekniske levering af en rapport skaber i sig selv ingen nytte. Fastlæg på forhånd, hvem der varetager kontakten med rua-modtageren, hvem der modtager og gemmer rapporterne, og hvor længe dataene skal opbevares. Da rapporter kan indeholde oplysninger om TLS-sessioner, skal adgangsrettigheder, databeskyttelseskrav og en procedure for sletning indgå i driftskonceptet. Der bør også være en eskaleringsregel for gentagne fejl.

Analysen kombinerer derfor to niveauer: TLSRPT viser sammenfattede tendenser over en periode, mens mailserverlogfiler giver et konkret billede af forløbet af de enkelte leveringsforsøg. Til den løbende overvågning supplerer Praktisk vejledning i overvågning af Postfix-logfiler rapporterne om metoder til klassificering af fejlmeddelelser og køer. Automatiske alarmer bør reagere på aktuelle driftsdata og ikke først på modtagne TLSRPT-aggregater.

Hvis der ikke er fastlagt en ansvarlig modtager, et sikkert arkiv eller en regelmæssig evaluering, bør offentliggørelsen i TLSRPT først planlægges i stedet for at blive iværksat forhastet. Ansvar for rapportering er en del af sikkerhedsfunktionen: Først når en fejl er tildelt en ansvarlig instans, er det muligt at reagere på en gennemsigtig måde, f.eks. på en udløbet MTA-STS-politik eller problemer med TLSA-data.

Vedligehold 3.10 eller skift til 3.11

Valget mellem patch-vedligeholdelse og skift af gren afhænger af udgangssituationen og driftsmålet. Postfix 3.10 er på tidspunktet for denne undersøgelse en legacy-gren, der stadig modtager opdateringer, mens 3.11 er den stabile udviklingsgren. Regelmæssige rettelser inden for 3.10 er derfor fornuftige for eksisterende installationer; de kan dog ikke sidestilles med en funktionsopgradering til 3.11.

En opgradering til 3.11 er især objektivt begrundet, hvis dens funktioner eller det langsigtede mål er nødvendige. REQUIRETLS og JSON-udskrifter fra bestemte administrationsværktøjer er dokumenteret som funktioner i den nyere gren og må ikke medregnes som Postfix 3.10-funktioner. Inden der skiftes gren, skal konfigurationsparametre, tilknyttede filtre, autentificering og automatisering kontrolleres for kompatibilitet.

For et stabilt 3.10-system uden behov for nye funktioner er løbende opdatering af programrettelser den umiddelbart passende foranstaltning. Den kræver dog stadig en kontrolleret proces med backup, pakkekontrol, validering, kontrol af procesaktivering og overvågning. Et skift af branche kræver derimod en faglig begrundelse og et planlagt vedligeholdelsesvindue; det højere versionsnummer er ikke i sig selv et tilstrækkeligt beslutningskriterium.