Dovecot-uppdatering: Nyheter i CE 2.4 och läget för Dovecot 3

Dovecot 3: Översikt över versionsstatus och utvecklingsplan

Den som planerar en uppdatering av Dovecot bör inte tolka versionsbeteckningarna som ett löfte om en kommande huvudversion. Vid tidpunkten för undersökningen, den 21 oktober 2026, är Dovecot CE 2.4.5 den publicerade stabila versionen i det officiella Core-arkivet. Däremot finns det inga uppgifter där om en publicerad Dovecot CE-version 3.0 eller en officiell CE 3.0-roadmap.

I synnerhet en rubrik som „v2.4.5 till v2.4.6“ i dokumentationen innebär inte att version 2.4.6 har släppts. Sådant innehåll kan hjälpa till att tidigt upptäcka förändringar i utvecklingsgrenen. Det ger dock ingen information om när, om eller i vilken form de kommer att införlivas i ett stabilt paket. Detta gäller i ännu högre grad för avledningar till Dovecot 3.

För beslut i Hosting av e-post Dessutom måste produktgrenarna hållas åtskilda. Dovecot CE avser Community Edition, medan Dovecot Pro är ett separat kommersiellt erbjudande. En funktion, en driftsmodell eller ett uttalande i dokumentationen kan därför inte automatiskt överföras mellan de båda. Även innehåll från main måste skiljas från publicerade CE-utgåvor; avgörande för en uppgradering är den version och den dokumentation som faktiskt ska användas.

Vad som har ändrats i versionsmodellen för Dovecot 2.4

Dovecot 2.4 skiljer mellan tre nivåer som ofta felaktigt likställs vid en uppdatering: den installerade programversionen, dovecot_config_version och dovecot_storage_version. Det installerade paketet avgör vilken kod IMAP-servern kan köra. De båda inställningarna styr däremot medvetet från vilken version ändrade standardvärden respektive nya lagringsformat ska användas.

Die Konfigurationsversion Detta förhindrar att ett paketbyte automatiskt aktiverar alla nya standardinställningar. Administratörer kan först uppdatera Dovecot till version 2.4 och därefter målmedvetet justera konfigurationsinställningarna efter att ha kontrollerat inloggning, TLS, plugins och befintliga inställningar. Detta minskar risken för överraskningar till följd av ändrade standardvärden, men ersätter inte den nödvändiga migreringen av en 2.3-konfiguration.

Die Lagringsversion gäller däremot dataformat som Dovecot skapar i sina index eller andra lagringsområden. Ett högre värde kan aktivera format som äldre versioner av Dovecot inte förstår. Därför bör det endast ställas in när en återgång till en äldre programversion inte längre ingår i återställningsplanen. En paketåtgång i sig återställer inte automatiskt tidigare använda indexformat.

För en migrering från version 2.3 till 2.4 måste båda inställningarna finnas i huvudkonfigurationen; dovecot_config_version då måste den första inställningen i dovecot.conf . Ställ in konfigurationsversionen till den avsedda målversionen först efter att du har anpassat och kontrollerat 2.4-syntaxen. Lagringsversionen förblir inledningsvis på den hittills nödvändiga kompatibla nivån och uppgraderas inte automatiskt till paketversionen.

Det uttryckliga andra steget är att godkännande som kräver återställning nya lagringsformat. Först när alla instanser använder den nya versionen, det inte längre är planerat att återgå till äldre Dovecot-versioner och ett avtalat underhållsfönster finns tillgängligt, kan dovecot_storage_version höjas till den valda måltavlan, till exempel till 2.4.5 för det trådindexformat som dokumenteras där. Äldre versioner kan återskapa detta index i sitt eget format, men detta medför extra arbete och ett byte mellan indexformat som inte är kompatibla med varandra. Uppgifterna utgör därför ingen färdig standardkonfiguration: utgångs- och målvärdena beror på vilken version som används och på reservplanen.

Denna stegvisa metod liknar principen att separat utvärdera programstatus och genomförda beteendeförändringar. Även när det gäller andra serverkomponenter räcker inte ett högt versionsnummer som bevis på kompatibilitet; bidraget till Beslut om uppgradering till Redis 8 förklarar denna skillnad för en annan tjänst. När det gäller Dovecot är dessutom postlådeformat, indexdata och reservstrategin relevanta.

Nya funktioner och deras mognadsgrad

En viktig nyhet i Dovecot 2.4 är fts-flatcurve som ett lokalt backend-system för fulltextsökning baserat på Xapian. Drivrutinen lagrar sökdata per postlåda i Dovecots indexväg och kräver Xapian version 1.4 eller senare. Den stöder relevansvärdering och kan även möjliggöra delsträngssökningar, men erbjuder ingen fuzzy-sökning. Utan ett fulltextindex måste Dovecot söka igenom meddelandedata sekventiellt för att hitta träffar.

Sökning efter delsträngar är inte automatiskt aktiverad i Flatcurve: Den dokumenterade standardinställningen för fts_flatcurve_substring_search lyder no. Om funktionen medvetet aktiveras för lämpliga IMAP-sökningar måste man räkna med att det krävs ytterligare lagringsutrymme för indexet. Flatcurve förblir därmed ett alternativ för IMAP-servrar där meddelandesökningar används regelbundet, men det är inte en obligatorisk uppgradering utan förbehåll. Indexökning, övervakning och omindexering ingår i driftsplaneringen.

SMTPUTF8 och IMAP ska klassificeras på ett annat sätt UTF8=ACCEPT och IMAP4rev2. I releaseinformationen betecknas dessa funktioner som experimentella. SMTPUTF8 och UTF8=ACCEPT skapar en build med --enable-experimental-mail-utf8 och därefter mail_utf8_extensions = yes i konfigurationen. IMAP4rev2 använder separata flaggor för detta: Vid kompileringen är --enable-experimental-imap4rev2 krävs, därefter måste imap4rev2_enabled = yes konfigureras.

Med ”experimentell” menas här inte att funktionen i allmänhet skulle vara olämplig. Det innebär snarare att den inte är en generell standard för alla webbhotellstjänster. Innan aktivering bör operatörer kontrollera om de e-postklienter som används, hela leveranskedjan och anslutna system verkligen behöver och kan hantera den önskade UTF-8-bearbetningen eller IMAP4rev2. Tester bör genomföras i en miljö som på ett tillräckligt sätt återspeglar verklig autentisering, postlådesnamn och klientprofiler.

Även SCRAM-mekanismer, TLS Channel Binding samt utökad TLS-SNI- och ALPN-hantering förtjänar en separat utvärdering. De berör inte bara Dovecot-processen, utan även samspelet med klienter, certifikat, proxyservrar och autentiseringskällor. Den rimliga måttstocken är ett tydligt behov med verifierbar kompatibilitet, inte enbart tillgången till en ny funktion i en Dovecot-version.

Systematiskt förbereda uppgraderingen till 2.4

En uppgradering från Dovecot 2.3 till 2.4 börjar med en inventering, inte med pakethanteraren. Kartlägg den installerade programversionen, den gällande konfigurationen och postlådans format, till exempel Maildir eller mdbox. Dokumentera dessutom autentiseringskällor, Sieve-regler, kvoter, fulltextsökning, replikering samt uppströmsproxyservrar. Endast på så sätt blir det tydligt vilka tjänster och datavägar som faktiskt påverkas av migreringen.

Följande kommandon lämpar sig för en läsbar inventering. De ändrar varken konfigurationen eller e-postdata; utdata bör dock endast visas i en skyddad arbetsmiljö, eftersom den kan ge upplysningar om servermiljön.

dovecot --version
doveconf -n

dovecot --version visar programstatusen. Med doveconf -n kontrollerar du den faktiska konfigurationen som avviker från standardvärdena. Alternativet -v Från doveadm är däremot ingen versionsförfrågan, utan aktiverar en mer detaljerad utmatning inklusive en förloppsindikator och hör endast till ett passande underkommando. Behandla konfigurationsutmatningen konfidentiellt: den kan innehålla värdnamn, katalogstrukturer, backend-adresser eller andra infrastrukturdetaljer. För felanalyser rekommenderar Dovecot-dokumentationen en minimerad konfiguration istället för en fullständig offentlig dump.

Kontrollera dessutom om den aktuella versionen redan är den senaste tillgängliga 2.3-versionen. Den dokumenterade migreringsvägen leder först till denna version och först därefter till 2.4. Överför inte konfigurationen direkt till ett produktionssystem, utan till ett testsystem med representativa konton, behörigheter och postlådestorlekar. Precis som vid en Kärnuppdatering för webbhotellsservrar Även här räcker inte versionsnumret i sig: paketeringen, de aktiverade modulerna och arkitekturen avgör den praktiska effekten.

Planera migreringen från 2.3 till 2.4

Övergången till version 2.4 är ett separat konfigurationssteg. Dovecot 2.4 kräver en anpassad syntax samt dovecot_config_version och dovecot_storage_version; konfigurationsversionen måste vara den första inställningen i dovecot.conf . Överför därför inte gamla filer utan ändringar. Jämför varje inställning som används med den versionsspecifika migreringsdokumentationen och verifiera den i testsystemet innan ett underhållsfönster planeras.

Tabellen innehåller inga alternativ. Den borttagna Director och den borttagna Replicator avser olika uppgifter: Enligt dokumentationen är Lua Director endast en lösning som inte stöds för små distributioner, medan ett delat filsystem anges som tillvägagångssätt för Replicator. doveadm sync är däremot efterföljaren till den borttagna dsync-Symlänkar och kan användas för medvetet planerade synkroniserings- eller migreringsprocesser; detta innebär dock inte att det finns någon dokumenterad direkt ersättning för Director eller Replicator.

Även när det gäller kvoter och sökningar är det den befintliga datamängden som avgör. Kompatibilitet Det innebär här inte bara att Dovecot startar: kvotvarningar, Sieve-åtgärder, IMAP-sökningar och åtkomst från flera klienter måste fungera med realistiska testkonton. Notera för varje komponent som tas bort var den är konfigurerad, vilka data den använder och hur en återgång ser ut. Först därefter går det att planera paketbytet på ett meningsfullt sätt.

Noggrant avväga sök- och lagringsformat

I Dovecot 2.4 kan programversionen, konfigurationsversionen och lagringsversionen utvecklas separat. Öka dovecot_storage_version först när det inte längre är planerat att gå tillbaka till en äldre version av Dovecot. Med Storage-Level 2.4.5 använder trådindexet för IMAP-kommandot THREAD ett nytt v2-format. Befintliga trådindex byggs upp på nytt vid nästa trådning; särskilt vid stora postlådor kan den första sökningen därför medföra extra arbete.

En äldre version av Dovecot förstår inte detta trådindexformat och skapar indexet i det gamla formatet igen. Den Lagringsnivå Det är därför en företagsintern bestämmelse, inte bara en kosmetisk förändring av versionen. Planera in eventuella omstruktureringar av indexet inom ett övervakat tidsfönster och utöka det inte samtidigt med ytterligare ändringar av sökfunktionen, lagringen eller proxytopologin som är svåra att ångra.

För lokala sökindex gäller att fts-flatcurve ett alternativ om miljön tillhandahåller Xapian 1.4 eller senare. Drivrutinen lagrar indexdata per postlåda i Dovecots indexväg och stöder relevansbedömning. Sökningar på delsträngar kan aktiveras och sker med fts_flatcurve_substring_search = no De är dock avstängda som standard och kräver betydligt mer indexminne när de aktiveras. Flatcurve stöder inte oskarp sökning.

Bedöm därför Sökarhitektur utifrån storleken på e-postlådorna, lagringstypen och driftsmodellen istället för en generell rangordning. doveadm fts flatcurve stats tillhandahåller lagrade statusdata för Flatcurve-indexen. Detta ska skiljas från doveadm fts flatcurve check: Detta kommando kontrollerar Xapian-databaser och försöker åtgärda grundläggande fel, vilket innebär att det kan förändra deras tillstånd. Rotering och borttagning av index är också specifika underhållsåtgärder. Planera inför sådana ingrepp vad gäller omfattning, berörda postlådor och eventuell återuppbyggnad av index.

Kontrollera silar, proxyservrar och säkerhetsgränser

Sieve-filter utgör en egen kontrollpunkt vid uppdateringen av Dovecot, eftersom tillägget inte ingår i Dovecots kärna: Sieve och ManageSieve tillhandahålls av det separata projektet Pigeonhole. Vid egenkompilerade installationer måste Pigeonhole kompileras om tillsammans med den nya Dovecot-versionen. Annars kan inte tolkningspluginet laddas på grund av en versionskonflikt.

Vid distributionsbaserade installationer är det istället avgörande att Dovecot- och Pigeonhole-paketen kommer från kompatibla paketkällor. Kontrollera före underhållsfönstret vilka aktiva användarskript, globala skript och ManageSieve-åtkomster som finns. Efter uppdateringen bör leverans, vidarebefordran, semesterbesvarelser och en ändring via ManageSieve testas med ett testkonto avsett för detta ändamål; produktiva filter ersätter inte detta test.

I proxyarkitekturer är det IMAP-komprimering särskild uppmärksamhet. När konfigurationsversionen uppgraderas till 2.4.5 blir standardinställningen för imap_compress_on_proxy yes. Bearbetningen av komprimeringen flyttas därmed till proxyservern; enligt dokumentationen hör inställningen hemma i backend. Förutsättningen är korrekt definierade login_trusted_networks samt tydliga gränser för tillit mellan proxy och backend.

Klargör därför innan du tillämpar den nya standardinställningen: Vilka anslutningar avslutas vid proxyn, vilka IP-adresser får backend-systemet betrakta som betrodda, och på vilket system ska CPU-belastningen och datatrafiken från komprimeringen ske? En ändring kan endast bedömas på ett meningsfullt sätt om dessa frågor stämmer överens med den faktiska nätverksarkitekturen. Den ersätter varken en TLS-kontroll eller en robust åtkomstkontroll mellan de berörda systemen.

Inte heller bör nya autentiseringsfunktioner och experimentella protokollfunktioner aktiveras generellt. I releaseinformationen nämns SCRAM-mekanismer, inklusive TLS Channel Binding samt SMTPUTF8, IMAP UTF8=ACCEPT och IMAP4rev2. SMTPUTF8 och UTF8=ACCEPT krävs vid kompileringen --enable-experimental-mail-utf8 och i konfigurationen mail_utf8_extensions = yes. Utöver detta använder IMAP4rev2 byggflaggan --enable-experimental-imap4rev2 och imap4rev2_enabled = yes i förväg. Kontrollera klientstöd, leveranskedjan och återfallsbeteendet för varje funktion separat innan du implementerar den i Hosting av e-post erbjuder.

Säker drift efter uppdateringen

En uppdatering är inte slutförd förrän tekniska kontroller har genomförts, inte redan efter att paketöverföringen har lyckats. Kontrollera först under underhållsfönstret om tjänsten startar och om loggarna visar på konfigurations-, plugin- eller behörighetsfel. Därefter följer inloggning och åtkomst till postlådan med ett testkonto. Kontrollera då åtminstone mappförteckningen, meddelandevalet, läsfunktionen och en kontrollerad leverans, så att IMAP-servern inte bara är tillgänglig utan också användbar.

Kontrollera att Sieve och Quota fungerar som separata funktioner. En lyckad IMAP-inloggning bevisar varken att Pigeonhole har laddats eller att kvotgränserna fastställs korrekt. Testa därför en ofarlig filterregel och en leverans nära en förutbestämd kvotgräns i en isolerad testpostlåda. På så sätt kan fel i plugins, behörigheter och anslutningen till respektive kvot-backend upptäckas utan att kundernas postlådor belastas avsiktligt.

När fulltextsökningen är aktiverad ska övervakningen av indexstatus och sökfrågor ske i efterbearbetningen. För en översiktlig genomgång av befintliga Flatcurve-indexdata används doveadm fts flatcurve stats. Underkommandot check Detta måste tydligt skiljas från det: Det kontrollerar Xapian-databaser och försöker åtgärda grundläggande fel, och är alltså inte en diagnostik som garanterat endast är läsbar. Använd den, precis som rotation eller borttagning av index, endast som en planerad underhållsåtgärd för specificerade postlådor och ta hänsyn till eventuella statusförändringar samt en ny indexuppbyggnad.

Om det finns proxyservrar i kedjan kontrollerar du dessutom hela trafikväg: När anmälan når den förväntade backend-servern, hanteras då klientens IP-adress och det betrodda nätverket korrekt, och uppstår inga oväntade komprimerings- eller TLS-problem? Jämför för detta ändamål loggarna från de berörda komponenterna tidsmässigt med varandra. Enstaka lyckade inloggningar räcker inte om flera backend-servrar, olika klientnätverk eller separata TLS-anslutningar är inblandade.

För felsökning rekommenderar Dovecot-dokumentationen en minimerad konfiguration. För att göra detta bör du, i en säker miljö, stegvis reducera konfigurationen till de komponenter som återskapar felet, istället för att publicera hela den produktiva konfigurationen. Varning: Information som till exempel den faktiska konfigurationen kan innehålla detaljer om infrastrukturen eller känsliga uppgifter. Dela därför inte denna information i sin helhet i ärenden, forum eller offentliga dokument, utan redigera den på ett målinriktat sätt.

När det lönar sig att uppdatera Dovecot

En uppdatering av Dovecot till CE 2.4.5 är inte bara ett beslut som rör funktioner och arkitektur. I releaseanteckningarna anges ett stort antal kritiska säkerhetsuppdateringar som bland annat rör IMAP-kommandon, Submission, OAuth-kontroller, dsync, autentisering och komprimering. Systemadministratörer bör därför omgående kontrollera om deras installation är drabbad och via vilken paket- eller backportversion den använda distributionen tillhandahåller korrigeringarna. Av uppströmsversionen i sig framgår varken att ett distributionspaket är opatchat eller att en generisk omedelbar uppgradering utan migrationskontroll skulle vara säker.

Utöver denna säkerhetsbedömning kan en uppdatering motiveras om den motiveras av nödvändig kompatibilitet, ett konkret driftskrav eller en modernisering som går att testa på ett begripligt sätt. Detta kan omfatta de kontrollerbara versionsväxlarna för konfiguration och lagring. Enbart paketversionen är dock inte tillräcklig för att fatta ett beslut: postlådans format, autentisering, kvot, Sieve, sökfunktion och proxytopologi avgör hur stor migreringsinsatsen faktiskt blir.

Det finns skäl att prioritera installationer på version 2.3, särskilt om säkerhetsläget och den tillgängliga distributionsversionen talar för en uppdatering och migreringen kan genomföras i ett testsystem. När det gäller lagringsnivån är man medvetet försiktig: nya lagringsformat bör först aktiveras när det inte längre finns någon möjlighet att återgå till äldre Dovecot-versioner. Detta gäller bland annat det trådindex som ändrades i version 2.4.5, vars omstrukturering sker vid nästa trådningsförfrågan.

Tilläggsfunktioner är separata arkitektoniska beslut. Flatcurve Det är lämpligt att överväga detta om nyhetssökning används regelbundet och om lokal indexlagring, beroende av Xapian, övervakning samt omindexering passar in i driftsmodellen. I dokumentationen klassificeras drivrutinen som ett lokalt, Xapian-baserat fulltextsökningsindex; detta innebär inte någon generell rekommendation framför Solr eller att man ska avstå från fulltextsökning.

Experimentella UTF8- och IMAP4rev2-alternativ är endast motiverade om det finns ett påvisat behov längs hela kedjan, från e-postklient till inlämning respektive leverans och IMAP-åtkomst. Utan denna förutsättning medför en aktivering framför allt en ökad kontrollinsats. Detsamma gäller för nya autentiseringsmekanismer: En befintlig funktion i versionen ersätter inte kontrollen av de använda klienterna, TLS-konfigurationen och autentiseringskällan.

När det gäller Dovecot 3 går det inte att utlova vare sig ett datum, en funktionsomfattning eller en migreringsplan utifrån den publicerade CE-informationen. Den bekräftade stabila versionen är CE 2.4.5; uppgifter i utvecklingsdokumentationen eller i grenen main är varken en offentliggjord produktversion eller en utvecklingsplan. Planera därför utifrån den faktiskt tillgängliga 2.4-serien, skilj den från Dovecot Pro och utvärdera senare tillkännagivanden först när de har offentliggjorts officiellt.