Dovecot Update: What's New in CE 2.4 and the Status of Dovecot 3

Dovecot 3: Understanding the Version Status and Roadmap

Anyone planning a Dovecot update should not interpret version numbers as a promise of an upcoming major release. As of October 21, 2026, Dovecot CE 2.4.5 is the published stable release in the official Core repository. However, there is no record of a published Dovecot CE version 3.0 or an official CE 3.0 roadmap there.

In particular, a heading such as „v2.4.5 to v2.4.6“ in the documentation does not indicate that a version 2.4.6 has been released. Such content can help identify changes in the development branch early on. However, it does not indicate when, if, or in what form these changes will be included in a stable package. This is especially true for versions derived from Dovecot 3.

For decisions regarding Email hosting In addition, the product lines must remain separate. Dovecot CE refers to the Community Edition, while Dovecot Pro is a separate commercial offering. Therefore, a feature, operating model, or documentation statement cannot automatically be transferred between the two. Content from the “main” branch must also be distinguished from published CE releases; the version and documentation that are actually intended for use are the determining factors for an upgrade.

What Has Changed in the Dovecot 2.4 Versioning Model

Dovecot 2.4 distinguishes between three levels that are often mistakenly conflated during an update: the installed version of the program, dovecot_config_version and dovecot_storage_version. The installed package determines which code the IMAP server can execute. The two settings, on the other hand, are specifically designed to control the point at which modified default values or new storage formats are used.

The Configuration Version This prevents a package update from silently activating all new defaults. Administrators can first update Dovecot to version 2.4 and then selectively upgrade the configuration semantics after reviewing authentication, TLS, plugins, and the existing settings. This reduces surprises caused by changed default values, but does not replace the necessary migration of a 2.3 configuration.

The Cache version In contrast, this setting affects the data formats that Dovecot uses in its indexes or other storage areas. A higher value may enable formats that older versions of Dovecot do not support. Therefore, it should only be set once rolling back to an older version is no longer part of the recovery plan. A package rollback alone does not automatically restore previously used index formats.

For a 2.3-to-2.4 migration, both settings must be present in the main configuration; dovecot_config_version The first setting must be dovecot.conf . Set the configuration version to the intended target level only after you have adapted and verified the 2.4 syntax. The storage version initially remains at the compatible level previously required and is not automatically updated to the package level.

The explicit second step is the rollback-critical release new storage formats. Only when all instances are using the new version, a rollback to older Dovecot versions is no longer planned, and a scheduled maintenance window is available, can dovecot_storage_version be increased to the selected target level, for example to 2.4.5 for the thread index format documented there. Older versions can reconstruct this index in their own format; however, this involves additional work and a switch between index formats that are not mutually compatible. Therefore, this information is not a ready-to-copy standard configuration: the source and target values depend on the version being used and the fallback plan.

This step-by-step approach is similar to the principle of evaluating the program status and implemented behavioral changes separately. Even for other server components, a high version number alone is not sufficient proof of compatibility; the article on Upgrade Decisions for Redis 8 explains this distinction for another service. With Dovecot, mailbox formats, index data, and the fallback strategy are also relevant.

New Features and Their Maturity Level

A notable new feature in Dovecot 2.4 is fts-flatcurve as a local full-text search backend based on Xapian. The driver stores search data for each mailbox in the Dovecot index path and requires Xapian version 1.4 or later. It supports relevance scoring and can also enable substring searches, but does not offer fuzzy search. Without a full-text index, Dovecot must search through message data sequentially to perform such searches.

Substring search is not automatically enabled in Flatcurve: The documented default setting for fts_flatcurve_substring_search is no. If it is intentionally enabled for relevant IMAP search queries, additional storage space must be allocated for the index. Flatcurve thus remains an option for IMAP servers with frequently used message search functionality, but it is not a mandatory upgrade without conditions. Index growth, monitoring, and reindexing are part of operational planning.

SMTPUTF8 and IMAP should be classified differently UTF8=ACCEPT and IMAP4rev2. The release notes label these features as experimental. SMTPUTF8 and UTF8=ACCEPT Create a build using --enable-experimental-mail-utf8 and then mail_utf8_extensions = yes in the configuration. IMAP4rev2 uses separate switches for this: During the build, --enable-experimental-imap4rev2 required; after that, you must imap4rev2_enabled = yes can be configured.

"Experimental" does not mean here that the feature is generally unsuitable. Rather, it is not a universal standard for every hosting service. Before enabling this feature, operators should verify whether the mail clients in use, the entire delivery chain, and connected systems actually require and are capable of handling the desired UTF-8 processing or IMAP4rev2. Tests should be conducted in an environment that adequately simulates real-world authentication, mailbox names, and client profiles.

SCRAM mechanisms, TLS channel binding, and advanced TLS SNI and ALPN processing also warrant a separate evaluation. They affect not only the Dovecot process but also its interaction with clients, certificates, proxies, and authentication sources. The appropriate criterion is a clear need with verifiable compatibility, not merely the availability of a new option in a Dovecot release.

Systematically Prepare for the Upgrade to 2.4

Upgrading from Dovecot 2.3 to 2.4 begins with an inventory check, not with the package manager. Record the installed version, the current configuration, and the mailbox format, such as Maildir or mdbox. Also document authentication sources, Sieve rules, quotas, full-text search, replication, and upstream proxies. This is the only way to determine which services and data paths are actually affected by the migration.

The following commands are suitable for a read-only inventory. They do not change the configuration or mail data; however, their output should be displayed in a secure workspace because it may reveal information about the server environment.

dovecot --version
doveconf -n

dovecot --version shows the program status. With doveconf -n you check the effective configuration that differs from the default settings. The option -v from doveadm In contrast, this is not a version query, but rather enables more detailed output—including a progress indicator—and is only associated with a corresponding subcommand. Treat the configuration output as confidential: it may contain hostnames, directory structures, backend addresses, or other infrastructure details. For error analysis, the Dovecot documentation recommends using a minimized configuration rather than an unabridged public dump.

Also check whether the current version is already the latest available 2.3 release. The documented migration path first leads to this version and only then to 2.4. Do not transfer the configuration directly to a production system; instead, transfer it to a test system with representative accounts, permissions, and mailbox sizes. As with a Kernel Update for Hosting Servers Here, too, the version number alone is not enough: packaging, enabled modules, and architecture determine the practical impact.

Planning the Migration from 2.3 to 2.4

Migrating to 2.4 is a separate configuration step. Dovecot 2.4 requires a modified syntax as well as dovecot_config_version and dovecot_storage_version; the configuration version must be the first setting in dovecot.conf Therefore, do not simply copy old files as-is. Compare each setting you use with the version-specific migration documentation and validate it in the test system before scheduling a maintenance window.

The table does not list any alternative solutions. The removed Director and the removed Replicator serve different purposes: According to the documentation, Lua Director is merely an unsupported solution for small deployments, whereas Replicator is described as an approach based on a shared file system. doveadm sync is, on the other hand, the successor to the removed dsync-Symlinks and can be used for intentionally planned synchronization or migration processes; however, this does not constitute a documented "drop-in" replacement for Director or Replicator.

The existing data set is also a determining factor when it comes to quotas and searches. Compatibility This doesn't just mean that Dovecot starts up: quota warnings, Sieve actions, IMAP searches, and access from multiple clients must work with realistic test accounts. For each component being removed, document where it is configured, what data it uses, and what the fallback plan is. Only then can the package migration be scheduled appropriately.

Carefully weigh the pros and cons of search and storage formats

In Dovecot 2.4, the program state, configuration state, and storage state can be developed separately by design. Increase dovecot_storage_version only when a rollback to an older version of Dovecot is no longer planned. With Storage Level 2.4.5, the thread index for the IMAP command THREAD A new v2 format. Existing thread indexes will be rebuilt during the next threading operation; this can result in additional overhead, especially for large mailboxes, during the initial query.

An older version of Dovecot does not understand this thread index format and generates the index in the old format again. The Storage Level It is therefore a company-wide policy, not merely a cosmetic change. Schedule any potential index rebuilds within a monitored time window, and do not perform them simultaneously with other changes to search, storage, or proxy topology that are difficult to reverse.

For local search indexes, fts-flatcurve An option if the environment provides Xapian 1.4 or later. The driver stores index data for each mailbox in the Dovecot index path and supports relevance scoring. Substring searches can be enabled using fts_flatcurve_substring_search = no However, they are disabled by default and require significantly more index memory when enabled. Flatcurve does not support fuzzy search.

So please rate the Search Architecture based on mailbox sizes, storage type, and operating model, rather than a blanket ranking. doveadm fts flatcurve stats provides stored status data for the Flatcurve indices. This should be distinguished from doveadm fts flatcurve check: This command checks Xapian databases and attempts to fix basic errors, so it may alter their state. Rotating and removing indexes are also targeted maintenance tasks. Before performing such operations, plan for the scope of the work, the mailboxes affected, and the possible need to rebuild the indexes.

Check Sieves, Proxies, and Security Limits

Sieve filters are a separate checkpoint during the Dovecot update because the extension is not part of the Dovecot core: Sieve and ManageSieve are provided by the separate Pigeonhole project. For installations built from source, Pigeonhole must be recompiled along with the new Dovecot version. Otherwise, the interpreter plugin will fail to load due to a version conflict.

For distribution-based installations, it is crucial that the Dovecot and Pigeonhole packages come from compatible package sources. Before the maintenance window, check which active user scripts, global scripts, and ManageSieve accounts are present. After the update, delivery, forwarding, vacation replies, and changes made via ManageSieve should be verified using a test account designated for this purpose; production filters are not a substitute for this test.

In proxy architectures, the IMAP Compression special attention. When the configuration version is updated to 2.4.5, the default for imap_compress_on_proxy yes. This shifts the handling of compression to the proxy; according to the documentation, this setting belongs on the backend. This requires correctly defined login_trusted_networks as well as transparent trust boundaries between the proxy and the backend.

Therefore, before adopting the new default, clarify the following: Which connections terminate at the proxy, which IP addresses should the backend treat as trustworthy, and on which system should the CPU load and data traffic resulting from compression occur? A change can only be properly evaluated if it aligns with the actual network architecture. It does not replace either TLS verification or robust access control between the involved systems.

New authentication and experimental protocol features should not be enabled by default either. The release notes mention SCRAM mechanisms, including TLS channel binding, as well as SMTPUTF8, IMAP UTF8=ACCEPT and IMAP4rev2. SMTPUTF8 and UTF8=ACCEPT are required during the build --enable-experimental-mail-utf8 and in the configuration mail_utf8_extensions = yes. Separately, IMAP4rev2 sets the build switch --enable-experimental-imap4rev2 and imap4rev2_enabled = yes First, check client support, the delivery chain, and fallback behavior for each function individually before you implement it in the Email hosting offer.

Operate Safely After the Update

An update is not complete until it has passed technical tests; it is not complete simply because the package installation was successful. During the maintenance window, first check whether the service starts and whether the logs show any configuration, plugin, or permission errors. Next, log in and access the mailbox using a test account. Be sure to check at least the folder list, message selection, reading, and a controlled delivery to ensure that the IMAP server is not only accessible but also functional.

Validate Sieve and Quota as separate functions. A successful IMAP login does not prove that Pigeonhole has been loaded, nor that quota limits are being determined correctly. Therefore, test a harmless filter rule and a delivery that comes close to a specified quota limit in an isolated test mailbox. This allows you to identify errors in plugins, permissions, and the connection to the respective quota backend without intentionally overloading customer mailboxes.

When full-text search is enabled, monitoring the index status and search queries is part of the post-processing. To get a quick overview of existing Flatcurve index data, use doveadm fts flatcurve stats. The subcommand check This must be clearly distinguished from the following: It checks Xapian databases and attempts to correct basic errors; therefore, it is not a guaranteed read-only diagnostic tool. Just like rotation or removing indexes, use it only as a scheduled maintenance task for specific mailboxes, and take into account possible changes in status as well as the need to rebuild the index.

With upstream proxies, you also control the entire Traffic route: Does the login request reach the expected backend, are the client IP and trusted network handled correctly, and do no unexpected compression or TLS issues arise? To verify this, compare the logs of the involved components over time. A few successful logins are not sufficient if multiple backends, different client networks, or separate TLS termination are involved.

For troubleshooting, the Dovecot documentation recommends using a minimal configuration. To do this, work step by step in a secure environment to narrow down the components that reproduce the error, rather than exposing the entire production configuration. Warning: Information such as effective configurations may contain infrastructure details or sensitive information. Therefore, do not share it in its entirety in tickets, forums, or public documents; instead, redact it as needed.

When It's Worth Updating Dovecot

Updating Dovecot to CE 2.4.5 is not just a matter of functionality and architecture. The release notes list numerous Critical security fixes including, among other things, IMAP commands, submission, OAuth checks, dsync, authentication, and compression. Administrators should therefore check as soon as possible whether their installation is affected and determine which package or backport version their distribution uses to provide the fixes. The upstream version alone does not indicate that a distribution package is unpatched, nor does it mean that a generic immediate upgrade without a migration check would be safe.

In addition to this security assessment, an update is justifiable if it is driven by a necessary compatibility requirement, a specific operational need, or a modernization that can be verifiably tested. This may include controllable version switches for configuration and storage. However, the package version alone is not a sufficient basis for a decision: mailbox format, authentication, quota, Sieve, search, and proxy topology determine how significant the migration effort actually is.

Prioritizing an upgrade to 2.3 is particularly advisable when the security situation and the available distribution version suggest an update, and the migration can be tested on a test system. However, the storage level remains deliberately conservative: New storage formats should only be enabled once a rollback to older Dovecot versions is no longer planned. This applies, among other things, to the thread index, which was changed in version 2.4.5 and is rebuilt during the next threading query.

Additional features are separate architectural decisions. Flatcurve It makes sense to consider this option if news search is used regularly and local index storage, Xapian dependency, monitoring, and reindexing fit the operational model. The documentation classifies the driver as a local, Xapian-based full-text search index; this does not imply a blanket recommendation over Solr or against using FTS.

Experimental UTF-8 and IMAP4rev2 options are justified only if there is a proven need throughout the entire chain—from the mail client, through submission or delivery, to IMAP access. Without this prerequisite, enabling these options primarily increases the verification effort. The same applies to new authentication mechanisms: An existing feature in the release does not replace the need to verify the clients in use, the TLS configuration, and the authentication source.

Based on the published CE information, it is not possible to provide a release date, a list of features, or a migration path for Dovecot 3. The current stable release is CE 2.4.5; references in the development documentation or in the branch main are not a published product status or roadmap. Therefore, plan based on the 2.4 line that is actually available, keep it separate from Dovecot Pro, and evaluate future announcements only once they have been officially released.