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.