Is there any chance of getting version 2.4.x available instead of 2.3x ? https://www.dovecot.org/download/ Thanks, Ian
^Triage: fix Summary and assign.
(In reply to Mark Linimon from comment #1) Thank you in advance
(In reply to Mark Linimon from comment #1) Tenable is always reporting a medium vulnerability with 2.3 Ian
Created attachment 260293 [details] Screenshot 1 I'll convert this to jpeg in a second
Created attachment 260294 [details] Screenshot2.1
Dovecot 2.4 introduces a new config file syntax, which *will* break existing installations [1]. However, 2.3.x will still receive security patches [2], hence I propose to create a new port for dovecot 2.4 (e.g. 'mail/dovecot24') to not break existing installations. We could add an informal message to pkg-descr about the new port and the required configuration changes by linking to [1]. [1] https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html [2] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L76DOC3NKUNSSPIXQNKINGOCYH5K/
+1 in keeping old dovecot23 for the time being I do like the replication functionality, thus will stay at dovecot23 BUT: I'd opt for upgrading mail/dovecot to 24, and kee a mail/dovecot23, instead. That will be better for a future dovecot25 version ;-)
(In reply to Michael Grimm from comment #7) This would still break existing installations. We could follow other ports where version updates need user intervention (and intention!) due to breakage, e.g. like with postgresql, python or php and add the version as flavours. OTOH - dovecot has a rather sane release cycle of several years with 2.3 being around since 2018. So this might be overkill. Introducing new versions with a suffix (24, 25) and converting 'mail/dovecot' to a meta-port/package *after* 2.3 is EOL and gone might be the cleanest and most straightforward way to keep it future-proof and not immediately break every mailserver. Anyways, to provide some actual code to the PR I tried to get 2.4 built. The diff is a very crude first attempt to 'just get it to build and run' with the default build options (plus PGSQL), so I'm sure there are still a lot of loose ends, especially when it comes to functionality provided by plugins that have been removed/replaced. The basic config file that is being installed works OOTB to start the service, however ALL example configuration known from earlier versions is gone. It seems they now only refer to the online documentation, but no longer provide example configuration with the tarball/source. I also haven't updated anything in the pkg-message, pkg-descr or other documentation yet.
Created attachment 260601 [details] new port: mail/dovecot24 diff to add dovecot 2.4 as a new port
Created attachment 260602 [details] diff dovecot -> dovecot24 actual diff from mail/dovecot to mail/dovecot24 for comparison
I agree that moving it all forward to 2.4 will be hard but I'd be willing to suffer that pain to eliminate the medium finding given it's an exposed port (even if geo-ip filtered along with fail2ban). I dunno, maybe I'm over thinking it but I have to believe it's going to bite us in the long run. $.02 Ian
I think there was some misunderstanding. Just to clarify: I'm not proposing that the actual service/binary/etc should be renamed 'dovecot24'; only the PORTNAME and PKGNAME. Just like with other ports where multiple versions are in the wild (e.g. postgresql, zabbix, openbgpd...) and the pkg/port name adds the version suffix, yet the actual binaries/service name etc don't.
I actually meant network port not FBSD port.
Any chance of getting this into the ports tree? Meanwhile, can I just duplicate mail/dovecot directory and apply the patch? Also, what about dovecot-pigeonhole ?
Among the old patches in the "files" directory, apparently only patch-src_plugins_fts_decode2text.sh is still relevant
Created attachment 262342 [details] mail/dovecot24-pigeonhole: add new port (In reply to Eugene R from comment #14) Regarding dovecot-pigeonhole: I wasn't able to get it to build because of various bugs if built without ldap: --- sieve-ldap-storage.lo --- sieve-ldap-storage.c:6:10: fatal error: 'ldap-utils.h' file not found 6 | #include "ldap-utils.h" | ^~~~~~~~~~~~~~ 1 error generated. *** [sieve-ldap-storage.lo] Error code 1 this header file is part of dovecot24 *if* it were built with LDAP; building pigeonhole with LDAP disabled (--with-ldap=no) still fails because it tries to include that header. This turned out it was a bug, so I tried the patch (https://github.com/dovecot/pigeonhole/commit/b37322a8d338bf999bc9774154dce79c4857d622.patch) from this bugreport: https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/S3ME4NFBRWU4EAOQRCMYG4MFD42ZVXYR/ but even then it still fails with a linker error because it still tries to include some ldap-specific files: ld: error: unable to find library -ldovecot-ldap cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libdovecot-sieve.la] Error code 1 There have been various patches regarding LDAP since v2.4.1, but I didn't have the time to sift through all of them to try which subset of them leads to a buildable variant of pigeonhole. If someone wants to deal with that mess, I've attached a patch for port 'www/dovecot24-pigeonhole' which I copied/adapted from the existing www/dovecot-pigeonhole port and contains the patch from the aforementioned bugreport. (In reply to Eugene R from comment #15) The upstream version is still the same (2.4.1), so I don't see why they should be obsolete? In fact, glancing over the commits since 2.4.1 (https://github.com/dovecot/core/compare/release-2.4.1...main) and the ammount (and nature) of crashes and memory leaks that were fixed since release 2.4.1, this port needs _A LOT_ more patches - or one should wait for the next release. TBH with bugs like "crashing when reloading config and logging to syslog", "memory leak when failing to connect to anvil" or "crash when trying to give multiple username parameters" and the cadence with which such bugs appear, I wouldn't want this anywhere near a production mailserver in its current state... I'd give it at least another year until they have sorted out the worst bugs (and CVEs) and then give it another look. However, anyone is welcome to use those patches and continue work from there and if I have some spare time available I'll be happy to help with testing.
Created attachment 262349 [details] mail/dovecot24 refined Refined dovecot24 port, builds and compiles cleanly on FreeBSD 14.3
I have uploaded the refined dovecot24 port. It now builds and compiles cleanly on FreeBSD 14.3. Major changes: - Removed patches from 2.3 that are obsolete or no longer relevant for 2.4 (bugs already fixed in upstream, Lucene support removed). - Handles installing dovecot.conf and dovecot.conf.sample correctly - Small fixes in pkg-plist (imap-hibernate not working on FreeBSD) - Updated pkg-message However, based on your report, I think I also will wait at least for 2.4.2 or 2.4.3 before switching )) Not sure I have time for handling all those patches in dovecot and pigeonhole
Oops, s/builds and compiles/builds and installs/ ))) Pity bugzilla comments can't be edited (
Dovecot 2.4.2 is out with a security fix. And there is now a plugin for replication support: https://codeberg.org/errror/wormhole
(In reply to Herbert J. Skuhra from comment #20) https://www.wiz.io/vulnerability-database/cve/cve-2025-30189 says ... The vulnerability was introduced in Dovecot version 2.4.1 ... so it seems, 2.3 is unaffected by this?
(In reply to Philip Jocks from comment #21) According to the announcement only 2.4.0 and 2.4.1 are affected: <https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/G3K5HMBKW6XOYNBXYV5GUM2GR6WPUD4M/>
Perhaps updating to dovecot 2.4 would be a good occasion to fix #290513 (building with LIBSODIUM in order to have Argon2id support).
https://dovecot.org/upgrader/
It might be worth noting this mail/thread[1] from the mailing list. In summary: Dovecot OY has pretty much moved all development efforts to the new 3.x tree, which is based on a completely new architecture called "Palomar"[2] (including "features" like "supports the interception of IMAP and POP3 protocol events, LMTP deliveries, appended messages, and more. Direct Integration with Lawful Intercept vendor APIs[...]" - YUCK!) This architecture is of course proprietary and incompatible with the 2.x tree. Given that 2.4 is still quite a mess (and not feature-complete to 2.3), I'd definitely hold on with any upgrades until it is clear if 2.4 will even be progressed or if (when) there will be a fork of 2.3 (which is the most logical path). So I'm still holding on to my proposal to add a new port (e.g. mail/dovecot24) instead of updating mail/dovecot to the 2.4 tree. Anyone willing to jump right into the 2.4 mess is welcome to do so, but one has to intentionally install that version. Breaking a lot of running installations and forcing them to re-build their configuration, just to have them possibly migrate back a few months later would be more than a "nuisance" (I'd be absolutely p*ssed...) and a violation of POLA (nobody wants to have a production service completely break by a pkg upgrade!) [1] https://lists.freebsd.org/archives/freebsd-ports/2026-January/009018.html [2] https://www.dovecotpro.com/solution
(In reply to Sebastian Oswald from comment #25) no problem with adding a new port so that anyone can test.
(In reply to Sebastian Oswald from comment #25) I'm just going to spitball some ideas I just thought of after reading what you wrote. Idea 1) cobble some kind of migration tool to version 3 is someone needs it. Maybe make it part of the port upgrade process if that's possible. I'm not a port maintainer so I don't know if that's really something that can be done. Idea 2) fork dovecot 2.3 or 2.4 and back port any patches. I imagine this going to be labor intensive but probably the best route in order to maintain configurations. Even then, who know how long this will work [I'm not a C/C++ coder] Idea 3) if we can scrub config options in version 3.x offer them to be scrubed. This might be a serious lift. I dunno. Or even if patches can be made to remove this MITM code. Idea 4) Once forked, it become something like dma is to sendmail - I think this idea is redundant. But since I throwing spaghetti at the wall.... I'm retired now at 59yrs old and I'm just trying to brainstorm from my old days. My real concern is that even though most if not all of us have geo-fenced this network port it's still exposed to the internet for some/most of us. Just thoughts, Ian