F43 Change Proposal: Dovecot 2.4 (self-contained)

:link: Dovecot 2.4

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Update the Dovecot email server in Fedora from Dovecot 2.3.x to Dovecot 2.4.x, the newest major release.

:link: Owner

:link: Detailed Description

Update the Dovecot email server in Fedora from Dovecot 2.3.x to Dovecot 2.4.x. This is the latest major release that upstream released after 7 years. Dovecot 2.3 and 2.4 configuration is not mutually compatible. Configuration upgrade process is documented at details see 2.3 to 2.4 | Dovecot CE

:link: Feedback

:link: Benefit to Fedora

With Dovecot 2.4 release, upstream shifted its support from 2.3.x to 2.4. Updating Dovecot in Fedora will allow to continue providing mail server that is secure, actively developed and maintained. List of changes and improvements at Release Dovecot v2.4.0 · dovecot/core · GitHub

:link: Scope

  • Proposal owners:
  • update dovecot rpm to 2.4, port downstream patches, testing
  • Other developers: N/A

  • Release engineering: N/A #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

Dovecot 2.4.x configuration is not compatible with 2.3.x configuration. Configuration changes and upgrade procedure is documented at 2.3 to 2.4 | Dovecot CE

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

  • if you already have dovecot installed
  1. backup

  2. update dovecot rpm

  3. update dovecot configuration as described 2.3 to 2.4 | Dovecot CE

  4. test that everything still works

:link: User Experience

Updated Dovecot 2.4.x provides more currently relevant security features and protocols. Easier configuration and deployment.

:link: Dependencies

NONE

:link: Contingency Plan

Worst case scenario, we can easily revert the change and delay for next Fedora release.

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2025-06-08T10:16:58Z

Last edited by @amoloney 2025-06-08T10:16:58Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Given that the configuration is not backward compatible, and that manual steps appears to be needed, what is the plan to handle this? What will happen on a dnf upgrade dovecot?

File placement, permissions, ownership
 do not change, so the upgrade will succeed, but service will not (re)start and log an error about wrong configuration. For small (home, diy) deployments package contains configuration that will work out-of-box, but as config files have noreplace attribute, it will still need manual change. The required changes are documented on upstream wiki 2.3 to 2.4 | Dovecot CE

Out of curiosity, what is the “proper” way for a Fedora admin to learn about
such breaking changes? I’m subscribed to the mailing list and this medium
here, so I see them; is that what PPL are expected to do?

I run a dovecot server in production (even thought he “production” in
question is small) on Fedora; imagine I run a distribution upgrade without
having read this notice here and then my mail setup is dead in the sand
(ironically, I couldn’t even read the announcement on the list anymore :sweat_smile:)..
that would be “annoying”.

Very hypothetical, I know :slightly_smiling_face:.

Proper way is to read release notes, that’s why they exist. For example link for Fedora 41: Release Notes :: Fedora Docs

RHEL/CentOS 9 isn’t compatible with RHEL/CentOS 10 either. If the change would be 100 % compatible, we would do the update during Fedora X live cycle and not wait.

You should always read release notes if you want to use the system in real production. If you use it for enterprise level production, you should also backup, update test machine, test and only after that update production machine.

but that’s sort of “Do as I say, not as I do” because I usually update first, fix SHTF later. With exception of Home Assistant as I can’t afford everything in house to stop working.

Fair enough. I was just sorta curious because for example in Gentoo land there
is eselect news which mostly tells you about breaking changes in the
terminal before you do stuff. I thought I might have missed something in
Fedora, but reading release notes is fair.