Postfix 3.10: Uppdateringar, TLSRPT och vägen mot 3.11

Att placera Postfix 3.10 i rätt tidsmässig kontext

Vid tidpunkten för undersökningen, den 20 oktober 2026, är Postfix 3.10 inte den aktuella stabila utvecklingsgrenen: den rollen har Postfix 3.11. Tillverkaren listar 3.10 som Legacy-grenen, men fortsätter att tillhandahålla fel- och säkerhetskorrigeringar för den. I de officiella meddelandena anges Postfix 3.10.14 från den 7 september 2026 som den senaste tillgängliga uppdateringen för denna gren.

Denna indelning skiljer mellan två olika beslut. En underhållsuppdatering från exempelvis 3.10.8 till en nyare 3.10-patch behåller den valda funktionsgrenen och införlivar dess korrigeringar. En uppgradering till 3.11 byter däremot utvecklingsgren och måste därför kontrolleras med avseende på ändrade funktioner, konfigurationskompatibilitet, tillägg och driftsflöden. En högre huvud- och sidogren är inte automatiskt den lämpliga åtgärden för varje produktionssystem.

För Linux-paket bör du, utöver den synliga Postfix-versionen, även kontrollera paketets metadata, ändringsloggen och säkerhetsmeddelandena från operativsystemleverantören. Ta reda på vilka korrigeringar just detta paket innehåller och om leverantören dokumenterar backports. Upstream-meddelandet beskriver däremot Postfix-utgåvan och utgör inte någon allmän backport-policy för en distribution.

För underhållsplaneringen innebär detta: Dokumentera först den installerade paketversionen, repositoriekanalen och de lokala anpassningarna. Jämför därefter vilka korrigeringar operativsystemets leverantör anger för detta paket. Först denna jämförelse visar om det finns någon utestående Uppdatering av Postfix om det krävs inom 3.10 eller om en planerad övergång till 3.11 skulle medföra ytterligare tekniska fördelar. Punkt 3.10.14 är i detta sammanhang en referenspunkt uppströms, inte en installationsanvisning för ett specifikt Linux-system.

MTA-roll, SMTP-portar och systembegränsningar

Postfix är ett Mail Transfer Agent (MTA). Den tar emot e-postmeddelanden via SMTP, beslutar utifrån sin routnings- och policykonfiguration om vidare bearbetning och vidarebefordrar meddelanden till andra e-postservrar eller lokala leveransvägar. På så sätt utgör Postfix transportlagret i en e-postserver under Linux. Konfigurationen avgör dock inte automatiskt hur användarna läser sina e-postkonton eller hur misstänkt innehåll bedöms.

En IMAP- eller POP3-server tillhandahåller postlådor för e-postprogram och är en annan komponent än SMTP-transporten. På samma sätt ersätter Postfix-funktioner inte en fullständig lösning för spam- eller virusfiltrering: sådana system måste vid behov kopplas in på rätt sätt, underhållas och övervakas. Denna åtskillnad är praktiskt relevant, eftersom ett lyckat SMTP-test varken bevisar att en e-postlåda kan hämtas eller att innehållskontrollen fungerar.

Port 25 används vanligtvis för SMTP-trafik mellan e-postservrar och därmed för den offentliga MX-driften. Portarna 587 och 465 är däremot avsedda för inlämning via e-postklienter, oftast med autentisering och en egen tjänstedefinition. Postfix hanterar dessa roller inte bara organisatoriskt på olika sätt: vissa inställningar får eller bör just inte gälla generellt för alla SMTP-tjänster.

Innan du gör några ändringar behöver du administratörsbehörighet, en återställningsbar säkerhetskopia av Postfix-konfigurationen och ett underhållsfönster som passar köer, leveranstider och anslutna applikationer. Notera dessutom om servern skickar utgående e-post, tar emot som en offentlig MX-server eller erbjuder klientinlämning. Dessa Upphörande av tjänstgöring förhindrar att ett dataskyddsbeslut som är meningsfullt för inlämning av anbud av misstag ändrar den offentligt tillgängliga porten 25.

TLSRPT kompletterar säker e-postleverans

Postfix 3.10 erbjuder valfritt stöd för TLSRPT i SMTP-klienten. Domäner kan via DNS publicera en mottagare för aggregerade TLS-rapporter; RFC 8460 tillåter e-postadresser och HTTPS-ändpunkter. Postfix rapporterar endast om TLS-handskakningar har lyckats eller misslyckats, högst en slutlig status per SMTP-anslutning. Misslyckade anslutningsförsök och avbrott före eller efter TLS-handskakningen registreras inte.

Versionsnumret 3.10 i sig är dock inte tillräckligt för att bevisa att ett installerat Postfix-paket faktiskt kan använda TLSRPT. Funktionen förutsätter att Postfix har ett TLSRPT-klientbibliotek som stöder funktionen samt byggalternativet USE_TLSRPT har skapats. Innan du planerar konfigurationen måste du därför, med hjälp av paketdokumentationen, de angivna byggegenskaperna och tillgängliga tilläggspaket, kontrollera om din distribution har detta stöd inbyggt.

TLSRPT kompletterar metoder som faktiskt påverkar TLS-skyddet vid en leverans. STARTTLS möjliggör förhandling om transportkryptering. DANE använder TLSA-poster och förutsätter DNSSEC för sina säkerhetsantaganden; MTA-STS publicerar en policy för förväntade TLS-egenskaper. Om en bindande DANE- eller MTA-STS-specifikation misslyckas kan TLSRPT leverera efterföljande information om sådana fel. Det aktiverar dock varken kryptering eller certifikatverifiering i sig.

Här måste man skilja mellan två roller. Den mottagande domänen publicerar en rua-slutpunkt och sköter eller anlitar någon för att övervaka mottagandet samt utvärdera inkommande rapporter. En rapporterande MTA behöver däremot en korrekt konfigurerad och aktiverad Postfix samt en separat infrastruktur som samlar in, hämtar, aggregerar och skickar rapporter. Dessa två perspektiv kan vara organisatoriskt åtskilda; en publicerande domäninnehavare behöver inte själv generera TLSRPT-rapporter på samma system.

Ett TLS-policy-plugin ingår därför inte generellt i varje TLSRPT-rapportkedja. Postfix stöder DANE på egen hand. Ett lämpligt plugin blir särskilt relevant när den avsändande MTA:n skickar MTA-STS-policyinformation via smtp_tls_policy_maps integrerar. Postfix 3.10 utökar svaren från ett sådant plugin med TLSRPT-relaterade attribut; detta innebär dock varken att varje installation behöver ett plugin, eller att TLSRPT ingår i varje 3.10-paket.

TLSRPT är dessutom ingen realtidsövervakning. I Postfix-handboken anges att det i genomsnitt tar cirka tolv timmar innan ett felmeddelande kommer fram, och därför skiljer man uttryckligen rapporterna från övervakning av akuta störningar. För pågående leveransproblem är det fortfarande nödvändigt att kontrollera köer, utvärdera loggar och utlösa larm. TLSRPT hjälper framför allt till att synliggöra återkommande mönster och policyproblem över många leveransförsök.

Förbereda en uppdatering av Postfix i 3.10-grenen

En uppdatering inom Postfix 3.10 är en underhållsåtgärd med tydliga utgångspunkter: Du uppdaterar en befintlig äldre gren till den patchnivå som tillhandahålls av din distribution. Säkerhetskopiera Postfix-konfigurationen innan du påbörjar arbetet och planera in ett underhållsfönster. Kontrollera dessutom om servern hanterar utgående leveranser, MX-trafik eller Submission, eftersom kontrollen och beredskapsplanen beror på detta.

Ta först reda på vilken version av Postfix som är installerad eller som programmet har hämtat information om, och dokumentera detta uttryckligen i main.cf inställda parametrar. De två första kommandona används för att göra en läsande inventering. postfix check är däremot ett administrativt underhållskommando: Det kontrollerar framför allt ägar- och åtkomsträttigheter för filer och kataloger och kan skapa kataloger som saknas. Kör det därför med de avsedda administrativa behörigheterna och inte under antagandet att filsystemet är garanterat oförändrat.

postconf mail_version
postconf -n
postfix check

Utgåvan av postconf mail_version anger versionen av den Postfix-programbas som startas. postconf -n visar parametrar med explicita name=value-poster i main.cf. Detta kan även omfatta inställningar vars värde överensstämmer med den aktuella inbyggda standardinställningen; utdata är därför inget säkert bevis på en faktisk avvikelse från standardinställningen. Efter en versionsuppdatering kan dessutom standardvärdena ändras, medan en tidigare angiven inställning kvarstår.

Dessutom postfix check är inte en fullständig validering av e-postserverns konfiguration. Kommandot kan rapportera problem med katalog- eller filbehörigheter och skapa saknade kataloger, men utvärderar inte på ett heltäckande sätt den tekniska korrektheten hos alla parametrar. Certifikatkedjor, externa kartor, DNS-beroenden, filter, autentisering och integrationen av anslutna tjänster måste kontrolleras separat.

Använd den uppdateringsmetod som stöds av din distribution för att uppdatera paketet. Kontrollera i paketets metadata, ändringslogg och säkerhetsmeddelanden vilka korrigeringar och eventuella backports det specifika paketet innehåller. Jämför dessa uppgifter med uppströmsmeddelandena. Dra inte slutsatsen att en patch saknas enbart på grund av en förkortad versionssträng.

Den särskilda skyldigheten att uppdatera processen, som beskrivs i Postfix dokumentation, gäller uppgradering från en äldre utvecklingsgren till Postfix 3.10.0. På grund av en ändring i det interna leveransagentprotokollet krävs därefter minst postfix reload eller krävs ett stopp följt av en start; annars kan budbärare inför en oväntad smtputf8-Attributet ”varna”. Denna motivering kan inte generellt tillämpas på alla senare patchuppdateringar inom version 3.10.

Vid underhållsuppdateringar inom 3.10-grenen kontrollerar du istället om paketverktyget redan har laddat om eller startat om tjänsten enligt distributionen och om de pågående processerna ingår i den uppdaterade versionen. Om så inte är fallet använder du den omladdning eller omstart som föreskrivs av distributionen och paketet. Kontrollera därefter köen och loggarna i underhållsfönstret, istället för att förutsätta ett specifikt aktiveringskommando oberoende av paketets beteende.

Planera TLSRPT med DNS och rapporteringsinfrastruktur

I TLSRPT måste rollen som mottagande domän och rollen som rapporterande MTA planeras separat. En domän som vill ta emot rapporter om leveranser till sin egen infrastruktur publicerar en rua-slutpunkt i DNS och säkerställer att mottagandet, skyddet, lagringen och utvärderingen av dessa sköts på ett korrekt sätt. TXT-posten anger därmed vart andra sändande MTA:er ska skicka sina sammanställda rapporter.

En MTA som själv ska generera TLSRPT-rapporter behöver, oavsett detta, ett Postfix-paket som innehåller ett TLSRPT-klientbibliotek och USE_TLSRPT byggdes. Uppgiften ”Postfix 3.10” bekräftar endast från vilken gren integrationen är tillgänglig; den anger inte byggegenskaperna för ett specifikt binärpaket. Kontrollera därför paketdokumentationen, bygginformationen och tillgängliga tilläggspaket i din distribution innan du planerar att använda funktionen.

På varje deltagande Postfix-system körs en lokal Collector ta emot händelser som överförs från det integrerade TLSRPT-biblioteket via en lokal Unix-domän-socket. Fetcher, den centrala aggregeringen och rapportgeneratorn kan drivas separat: De hämtar de insamlade uppgifterna, skapar de avsedda sammanfattningarna och skickar rapporter till de mål som publicerats av mottagardomänerna. Dessa nedströmskomponenter kan vara centraliserade på andra system; den lokala insamlaren på respektive Postfix-system kan dock inte ersättas av detta.

En Policy-plugin krävs endast i vissa fall på sändarsidan. Om MTA använder MTA-STS-policyinformation via smtp_tls_policy_maps, måste det plugin som används för detta stödja de TLSRPT-relaterade attributen. DANE stöds av Postfix självt. Varken DNS-posten för en mottagande domän eller rapportbearbetningen i en lämpligt konfigurerad MTA kräver därför generellt sett ett MTA-STS-plugin.

Följande post beskriver uteslutande DNS-syntaxen för en rapportmottagare. example.invalid är avsiktligt inte en produktiv domän och får inte användas i oförändrat skick. Taggen v=TLSRPTv1 kännetecknar förfarandet; rua Anger här en destination för rapporter. RFC 8460 tillåter förutom e-post även HTTPS-ändpunkter.

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

För TLSRPT-rapporter definierar Postfix 3.10 rubriken TLS-Required: no, så att rapporten kan sänkas till säkerhetsnivån „may“ vid överföringen via TLS. Detta strikt avgränsade undantag förhindrar att en felrapport avvisas på grund av strikta TLS-krav. Det är inte en anvisning om att sänka TLS-kraven för vanliga affärs- eller användar-e-postmeddelanden.

Skydda överföringen, utvärdera TLS-alternativen noggrant

Inställningen smtpd_hide_client_session gäller för autentiserad inlämning från e-postklienter. Om den är aktiverad skapar SMTP-servern Received:-rubriker utan information från klientsessionen. Beroende på session kan därmed exempelvis klientens värdnamn och IP-adress, TLS-sessionsdata, SASL-inloggningsuppgifter samt SMTP-loggdetaljer döljas i rubriken.

Ordna dessa Sekretessfunktion en särskild definition av inlämningstjänsten för port 587 eller 465, istället för att generellt ange den globalt i main.cf för att aktivera den. Den offentliga MTA:n på port 25 har en annan roll vid server-till-server-överföring. I Postfix-dokumentationen krävs standardvärdet där för att kraven i RFC 5321 ska uppfyllas.

Beslutet rör alltså inte bara integriteten, utan även spårbarhet och tjänstens gränser. För autentiserade klienter kan det vara lämpligt att minska mängden onödiga metadata. På en offentlig MX-server skulle samma inställning dock strida mot de dokumenterade förväntningarna på ”Received:”-information. Överväg därför separata tjänster, lyssnare och deras respektive parametrar istället för en enhetlig global regel.

Postfix 3.10.0 innehåller dessutom en anpassning för OpenSSL 3.5 och dess gruppsyntax för postkvantumkryptografi. Om man medvetet vill delegera valet av grupper helt till den centralt underhållna OpenSSL-konfigurationen måste tls_eecdh_auto_curves och tls_ffdhe_auto_groups båda måste vara tomma. Det är först när båda är tomma som OpenSSL får välja; Postfix stöder inte den nya OpenSSL-syntaxen i sig.

Att tömma båda de automatiska parametrarna är en Särskilt fall för centralt hanterade krypteringsinställningar, ingen allmän rekommendation om säkerhetsförstärkning. Detta är endast lämpligt om den faktiska OpenSSL-konfigurationen är känd, versionsspecificerad och testad. Om denna kontroll saknas kan överföringen av valet dölja felkonfigurationer eller skapa oväntade TLS-egenskaper; i sådana fall är de explicita Postfix-inställningarna mer spårbara.

Kontrollera uppdateringsstatus och kända fel

Versionsangivelsen 3.10 i sig beskriver inte någon enhetlig teknisk nivå. Avgörande är den konkreta patchversionen, uppgifterna i distributionspaketets ändringslogg och, i förekommande fall, bakåtportade korrigeringar. Postfix 3.10.14 tillkännagavs den 7 september 2026 som en äldre version tillsammans med andra underhållna grenar. Detta innebär inte att varje Linux-paket redan innehåller denna uppströmsversion.

Ett konkret exempel är Postfix 3.10.6: Denna version åtgärdade ett problem som rörde TLS krävs: nej och TLS-wrapperläge på klientsidan. Den tidigare implementeringen kunde påverka sådana anslutningar negativt; korrigeringen hanterar dem med säkerhetsnivån encrypt. Den som använder SMTPS-wrapper-läge bör därför kontrollera patchstatus och den faktiskt använda överföringsvägen, istället för att dra slutsatser om samma beteende utifrån „3.10“.

I meddelandet om version 3.10.14 nämns bland annat korrigeringar och förstärkningar av säkerheten för en SMTP-smuggling-konstellation med smtpd_proxy_filter. Detta innebär inte att alla e-postservrar är drabbade: parametern är inaktiverad som standard, och huruvida detta är relevant beror på den lokala konfigurationen samt den uppströms liggande eller anslutna filterarkitekturen. Kontrollera därför först om denna funktion överhuvudtaget används aktivt.

Vid onormala leveranser bör felsökningen följa en logisk ordning: Först kontrollerar du faktiska avvikelser och konfigurationsvalideringen, sedan om omladdningen har genomförts efter en uppgradering. Därefter undersöker du köerna och loggarna för återkommande TLS-, anslutnings- eller Deferred-meddelanden. En systematisk guide till Analys av Postfix-loggar hjälper till att koppla enskilda händelser till ett kö-ID och dess leveransförsök.

Varning: En versionsuppdatering ersätter inte en orsaksanalys. En omstart löser varken ogiltiga certifikatkedjor, DNS-fel eller felaktiga routningsregler. Omvänt kan uteblivna omstarter efter en uppgradering dölja förändrade processer eller konfigurationer i driften. Dokumentera därför gemensamt patchstatus, paketkälla, tidpunkt för aktivering och observerade loggmeddelanden.

Att korrekt utvärdera TLSRPT-rapporter under drift

TLSRPT-rapporter är fördröjda och ersätter inte övervakning i realtid. Enligt Postfix-dokumentationen tar det i genomsnitt cirka tolv timmar innan en felrapport anländer. I Postfix avser de registrerade resultaten TLS-handshakes; fel vid uppkoppling och avbrott före eller efter handshaken saknas. För akuta händelser krävs fortfarande köövervakning, logganalys och larm.

Även återanvändning begränsar räkningen: En återanvänd SMTP-anslutning genererar ingen ytterligare TLS-handskakning. Vid återupptagna TLS-sessioner hoppar Postfix 3.10 som standard över registreringen; för detta är smtp_tlsrpt_skip_reused_handshakes avgörande. Rapporteringssammantagningarna är därför varken ett fullständigt antal av alla SMTP-anslutningar eller en meddelande- eller leveransgrad. Utvärdera felkategorier, mottagardomäner, tidsperioder och återkommande mönster tillsammans med serverloggarna.

Att en rapport skickas på ett tekniskt sätt innebär inte automatiskt någon nytta. Fastställ i förväg vem som ansvarar för rua-mottagaren, vem som tar emot och sparar rapporterna samt hur länge uppgifterna ska bevaras. Eftersom rapporter kan innehålla information om TLS-sessioner bör åtkomsträttigheter, dataskyddsriktlinjer och en rutin för radering ingå i driftskonceptet. Det bör även finnas en eskaleringsregel för återkommande fel.

Analysen kombinerar därför två nivåer: TLSRPT visar sammanfattade trender över en viss tidsperiod, medan e-postserverloggarna ger en detaljerad bild av hur enskilda leveransförsök har förloppit. För den löpande övervakningen kompletterar Praktisk guide till övervakning av Postfix-loggar rapporterna om metoder för klassificering av felmeddelanden och köer. Automatiska larm bör reagera på aktuella driftsdata, inte först på mottagna TLSRPT-aggregat.

Om det inte finns någon ansvarig mottagare, något säkert arkiv eller någon regelbunden utvärdering bör publiceringen i TLSRPT först planeras istället för att aktiveras förhastat. Ansvar för rapporteringen är en del av säkerhetsfunktionen: Det är först när ett fel tilldelas en ansvarig instans som det blir möjligt att vidta en spårbar åtgärd, till exempel vid en utgången MTA-STS-policy eller problem med TLSA-data.

Underhålla 3.10 eller byta till 3.11

Valet mellan att fortsätta med patch-underhåll eller byta gren beror på utgångsläget och verksamhetens mål. Postfix 3.10 är, vid tidpunkten för denna undersökning, en äldre gren som fortfarande får uppdateringar, medan 3.11 är den stabila utvecklingsgrenen. Regelbundna korrigeringar inom 3.10 är därför lämpliga för befintliga installationer; de kan dock inte likställas med en funktionsuppgradering till 3.11.

En övergång till 3.11 är framför allt motiverad ur saklig synvinkel om dess funktioner eller det långsiktiga målet behövs. REQUIRETLS och JSON-utdata från vissa administrationsverktyg är dokumenterade som funktioner i den nyare grenen och får inte planeras in som funktioner i Postfix 3.10. Innan ett grenförskjutning genomförs måste konfigurationsparametrar, kopplade filter, autentisering och automatisering kontrolleras med avseende på kompatibilitet.

För ett stabilt 3.10-system utan behov av nya funktioner krävs kontinuerlig uppdatering av patchar den omedelbart lämpliga åtgärden. Den kräver dock ett kontrollerat förfarande med säkerhetskopiering, paketkontroll, validering, kontroll av processaktivering och övervakning. Ett byte av bransch kräver däremot ett sakligt skäl och ett planerat underhållsfönster; enbart det högre versionsnumret är inte ett tillräckligt beslutskriterium.