Re: The end of Dovecot Director?
If the community has enough resources to fork the whole project, it would probably be far more efficient and easier to just fork the Director component. I’m not familiar enough with dovecot sources to tell if this is possible, but if the community really wants to keep Director alive, maybe it should start investigating if building it as an out of tree component is possible ? > Le 2 nov. 2022 à 17:46, Jan Hugo Prins a écrit : > > I think the only thing they will gain is a community that is angry and will > in the end leave the product / fork the complete product. > > Jan Hugo > > On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz wrote: > On 11/2/22 03:54, Aki Tuomi wrote: > On 02/11/2022 11:55 EET Frank Wall wrote: > > On 2022-11-02 09:11, Aki Tuomi wrote: > You can also see the email sent by others which shows how you can do > this without replication, using proxy and passdb to direct users to > right backend. Which is basically what director does. > It's not the same thing. > > It is not critical functionality. You can feasibly run a two-node > dovecot system on NFS without having director. > It seems to be critical enough to offer a replacement for paying > customers, while at the same time leaving the community edition > with no valid replacement. > > > Ciao > - Frank > Can you tell me what kind of functionality you are unable to achieve with the > passdb solution? > > Aki > > Can you tell us what you are gaining (other than monitarily) by removing a > completely functionally working feature that numerous people are using? > > Adding new paid features is one thing (i.e. nginx), taking away a feature to > replace it with a paid feature is something completely different. > > -- > Brad > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
One of our developers wrote the whole LDAP integration in Dovecot, and I for one am not happy with this move. Jan Hugo On November 2, 2022 6:16:21 PM GMT+01:00, Dave McGuire wrote: > > It would certainly be a shame if that sort of thing started happening with > Dovecot. Since day one, the Dovecot community has always been very pleasant, > friendly, and drama-free. If forks start happening due to profiteering, that > will irrevocably change the Dovecot community, with feelings of broken trust. > > That would be a shame. > > No one decries the commercial side of Dovecot wanting to make money. Timo > and others have worked very hard on this project for many years. I was a > very early adopter of Dovecot, a refugee from (the awful) Cyrus IMAP server, > and I watched it grow up to be a highly useful and widely respected package. > Creating a commercial version to reward the developers and fund future > development is fine; I applaud it. > > But it really smells like the current move with Director is crossing a line. > > Those in charge of making this decision would do well to pay very close > attention here. > >-Dave > >On 11/2/22 12:46, Jan Hugo Prins wrote: >> I think the only thing they will gain is a community that is angry and will >> in the end leave the product / fork the complete product. >> >> Jan Hugo >> >> On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz >> wrote: >> >> On 11/2/22 03:54, Aki Tuomi wrote: >> >> On 02/11/2022 11:55 EET Frank Wall wrote: >> >> On 2022-11-02 09:11, Aki Tuomi wrote: >> >> You can also see the email sent by others which shows >> how you can do >> this without replication, using proxy and passdb to >> direct users to >> right backend. Which is basically what director does. >> >> It's not the same thing. >> >> It is not critical functionality. You can feasibly run a >> two-node >> dovecot system on NFS without having director. >> >> It seems to be critical enough to offer a replacement for paying >> customers, while at the same time leaving the community edition >> with no valid replacement. >> >> >> Ciao >> - Frank >> >> Can you tell me what kind of functionality you are unable to >> achieve with the passdb solution? >> >> Aki >> >> >> Can you tell us what you are gaining (other than monitarily) by removing >> a completely functionally working feature that numerous people are using? >> >> Adding new paid features is one thing (i.e. nginx), taking away a >> feature to replace it with a paid feature is something completely different. >> >> -- Brad >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >-- >Dave McGuire, AK4HZ >New Kensington, PA > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
It would certainly be a shame if that sort of thing started happening with Dovecot. Since day one, the Dovecot community has always been very pleasant, friendly, and drama-free. If forks start happening due to profiteering, that will irrevocably change the Dovecot community, with feelings of broken trust. That would be a shame. No one decries the commercial side of Dovecot wanting to make money. Timo and others have worked very hard on this project for many years. I was a very early adopter of Dovecot, a refugee from (the awful) Cyrus IMAP server, and I watched it grow up to be a highly useful and widely respected package. Creating a commercial version to reward the developers and fund future development is fine; I applaud it. But it really smells like the current move with Director is crossing a line. Those in charge of making this decision would do well to pay very close attention here. -Dave On 11/2/22 12:46, Jan Hugo Prins wrote: I think the only thing they will gain is a community that is angry and will in the end leave the product / fork the complete product. Jan Hugo On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz wrote: On 11/2/22 03:54, Aki Tuomi wrote: On 02/11/2022 11:55 EET Frank Wall wrote: On 2022-11-02 09:11, Aki Tuomi wrote: You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. It's not the same thing. It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. It seems to be critical enough to offer a replacement for paying customers, while at the same time leaving the community edition with no valid replacement. Ciao - Frank Can you tell me what kind of functionality you are unable to achieve with the passdb solution? Aki Can you tell us what you are gaining (other than monitarily) by removing a completely functionally working feature that numerous people are using? Adding new paid features is one thing (i.e. nginx), taking away a feature to replace it with a paid feature is something completely different. -- Brad -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Dave McGuire, AK4HZ New Kensington, PA
Re: The end of Dovecot Director?
I think the only thing they will gain is a community that is angry and will in the end leave the product / fork the complete product. Jan Hugo On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz wrote: >On 11/2/22 03:54, Aki Tuomi wrote: >>> On 02/11/2022 11:55 EET Frank Wall wrote: >>> >>> On 2022-11-02 09:11, Aki Tuomi wrote: You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. >>> It's not the same thing. >>> It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. >>> It seems to be critical enough to offer a replacement for paying >>> customers, while at the same time leaving the community edition >>> with no valid replacement. >>> >>> >>> Ciao >>> - Frank >> Can you tell me what kind of functionality you are unable to achieve with >> the passdb solution? >> >> Aki > >Can you tell us what you are gaining (other than monitarily) by removing a >completely functionally working feature that numerous people are using? > >Adding new paid features is one thing (i.e. nginx), taking away a feature to >replace it with a paid feature is something completely different. > >-- >Brad > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
On 11/2/22 03:54, Aki Tuomi wrote: On 02/11/2022 11:55 EET Frank Wall wrote: On 2022-11-02 09:11, Aki Tuomi wrote: You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. It's not the same thing. It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. It seems to be critical enough to offer a replacement for paying customers, while at the same time leaving the community edition with no valid replacement. Ciao - Frank Can you tell me what kind of functionality you are unable to achieve with the passdb solution? Aki Can you tell us what you are gaining (other than monitarily) by removing a completely functionally working feature that numerous people are using? Adding new paid features is one thing (i.e. nginx), taking away a feature to replace it with a paid feature is something completely different. -- Brad
Re: The end of Dovecot Director?
> On 02/11/2022 11:55 EET Frank Wall wrote: > > > On 2022-11-02 09:11, Aki Tuomi wrote: > > You can also see the email sent by others which shows how you can do > > this without replication, using proxy and passdb to direct users to > > right backend. Which is basically what director does. > > It's not the same thing. > > > It is not critical functionality. You can feasibly run a two-node > > dovecot system on NFS without having director. > > It seems to be critical enough to offer a replacement for paying > customers, while at the same time leaving the community edition > with no valid replacement. > > > Ciao > - Frank Can you tell me what kind of functionality you are unable to achieve with the passdb solution? Aki
Re: The end of Dovecot Director?
On 2022-11-02 09:11, Aki Tuomi wrote: You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. It's not the same thing. It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. It seems to be critical enough to offer a replacement for paying customers, while at the same time leaving the community edition with no valid replacement. Ciao - Frank
Re: The end of Dovecot Director?
> On 01/11/2022 17:58 EET Mark Moseley wrote: > > > TL;DR: > > Sure, this affects medium/large/Enterprise folks (that's where I was using > Director -- though currently retired, so no existing self-interest in this > email). > > This will also affect *any* installation with a whopping two dovecot servers > with mdbox backends talking to a single linux NFS server as well. That's not > exactly "Enterprise". Replication is great, but it is not a replacement for > Director (nor is any sort of load balancing, regardless of the confused > comments in this thread about nginx). > You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. > > I think the real issue here is that Dovecot is removing existing, > long-standing, critical functionality from the open source version. That is a > huge, huge red flag. > It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. > I'm also a little bewildered by the comment "Director never worked especially > well". Worked great for me, at scale, for years. Complex? Yup, but that was > the price of mdbox (worth it). And if you're setting up a proxy cluster > (instead of a full Director cluster) in front of your IMAP servers, you've > already tackled 90% of the complexity anyway (i.e. using Director isn't the > hard part). > And replacing director with a passdb that does the same isn't hard either. > This *feels" to me like a parent company looking to remove features from the > open source version in order to add feature differentiation to the paid > version. > > I've loved the Dovecot project for over a decade and a half. And incidentally > I have a very warm spot in my heart for Timo and Aki, thanks to Dovecot and > especially this mailing list. > > I've also loved the PowerDNS project for a decade and a half, so this removal > of existing functionality is doubly worrisome. I'd like both projects to be > monetisable and profitable enough to their parent so that they continue on > for a very, very long time. > > But removing long-standing features is a bad look. Please reconsider this > decision. > > Our strategy for the community version of Dovecot 3.0 forward is to be able to run a 1-2 node Dovecot backend (so you can have a primary/backup backend), with a proxy in front of it. Aki
Re: The end of Dovecot Director?
On 2022-11-01 16:58, Mark Moseley wrote: This *feels" to me like a parent company looking to remove features from the open source version in order to add feature differentiation to the paid version. I've loved the Dovecot project for over a decade and a half. And incidentally I have a very warm spot in my heart for Timo and Aki, thanks to Dovecot and especially this mailing list. I've also loved the PowerDNS project for a decade and a half, so this removal of _existing functionality_ is doubly worrisome. I'd like both projects to be monetisable and profitable enough to their parent so that they continue on for a very, very long time. But removing long-standing features is a bad look. Please reconsider this decision. Big +1 --- Tom
Re: The end of Dovecot Director?
Frank Wall skrev den 2022-11-01 23:44: On 2022-11-01 16:58, Mark Moseley wrote: TL;DR: I think the real issue here is that Dovecot is removing *existing, long-standing, critical functionality* from the open source version. That is a huge, huge red flag. It certainly looks like a poor decision, driven by corporate interests. Makes me wonder which other feature will be moved to the commercial edition once the dust has settled. same as outlook.com mail with non public blacklists, and hard to know why its default are block all mail, and on top of that uses previous ip listnings from old abuseing custommers, same shit, sorbs came to mind there, not checking owner of mtas, isp/vps not update sorbs dnsbl listnings, sorbs not helping recovery logins if one lost it It really hurts the great reputation Dovecot has built over all these years. I've got my first Dovecot installation back in ~2006 and ever since I've been advocating it as the best IMAP server. So sad to see this feature removal now. on that there is only cyrus-imapd, if dovecot is loosing to much i would change over to if i need to, more stable since no updates, no bugs :) i am not joking btw for the moment i just keep using dovecot
Re: The end of Dovecot Director?
On 2022-11-01 16:58, Mark Moseley wrote: TL;DR: I think the real issue here is that Dovecot is removing *existing, long-standing, critical functionality* from the open source version. That is a huge, huge red flag. It certainly looks like a poor decision, driven by corporate interests. Makes me wonder which other feature will be moved to the commercial edition once the dust has settled. It really hurts the great reputation Dovecot has built over all these years. I've got my first Dovecot installation back in ~2006 and ever since I've been advocating it as the best IMAP server. So sad to see this feature removal now. Ciao - Frank
Re: The end of Dovecot Director?
I think the real issue here is that Dovecot is removing _existing, long-standing, critical_ functionality from the open source version. That is a huge, huge red flag. Clear enough. It would be great if dovecot decides to keep it in one way or another in community release.
Re: The end of Dovecot Director?
TL;DR: Sure, this affects medium/large/Enterprise folks (that's where I was using Director -- though currently retired, so no existing self-interest in this email). This will also affect *any* installation with a whopping two dovecot servers with mdbox backends talking to a single linux NFS server as well. That's not exactly "Enterprise". Replication is great, but it is not a replacement for Director (nor is any sort of load balancing, regardless of the confused comments in this thread about nginx). I think the real issue here is that Dovecot is removing *existing, long-standing, critical functionality* from the open source version. That is a huge, huge red flag. I'm also a little bewildered by the comment "Director never worked especially well". Worked great for me, at scale, for years. Complex? Yup, but that was the price of mdbox (worth it). And if you're setting up a proxy cluster (instead of a full Director cluster) in front of your IMAP servers, you've already tackled 90% of the complexity anyway (i.e. using Director isn't the hard part). This *feels" to me like a parent company looking to remove features from the open source version in order to add feature differentiation to the paid version. I've loved the Dovecot project for over a decade and a half. And incidentally I have a very warm spot in my heart for Timo and Aki, thanks to Dovecot and especially this mailing list. I've also loved the PowerDNS project for a decade and a half, so this removal of *existing functionality* is doubly worrisome. I'd like both projects to be monetisable and profitable enough to their parent so that they continue on for a very, very long time. But removing long-standing features is a bad look. Please reconsider this decision. On Thu, Oct 27, 2022 at 4:04 AM Jan Bramkamp wrote: > On 27.10.22 04:24, Timo Sirainen wrote: > > Director never worked especially well, and for most use cases it's just > unnecessarily complex. I think usually it could be replaced with: > > > > * Database (sql/ldap/whatever) containing user -> backend table. > > * Configure Dovecot proxy to use this database as passdb. > > * For HA change dovemon to update the database if backend is down to > move users elsewhere > > * When backend comes up, move users into it. Set delay_until extra > field for user in passdb to 5 seconds into future and kick the user in its > old backend (e.g. via doveadm HTTP API). > > > > All this can be done with existing Dovecot. Should be much easier to > build a project doing this than forking director. > Thank you for putting what is about to be lost to the community edition > into an operational perspectiv: no reason to panic. Nobody is taking > replicated active-passive pairs from small to medium scale operators. > Neither are the hooks required for more fancy load balancing and > steering on the chopping block. >
Re: The end of Dovecot Director?
On 27.10.22 04:24, Timo Sirainen wrote: Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with: * Database (sql/ldap/whatever) containing user -> backend table. * Configure Dovecot proxy to use this database as passdb. * For HA change dovemon to update the database if backend is down to move users elsewhere * When backend comes up, move users into it. Set delay_until extra field for user in passdb to 5 seconds into future and kick the user in its old backend (e.g. via doveadm HTTP API). All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director. Thank you for putting what is about to be lost to the community edition into an operational perspectiv: no reason to panic. Nobody is taking replicated active-passive pairs from small to medium scale operators. Neither are the hooks required for more fancy load balancing and steering on the chopping block.
Re: The end of Dovecot Director?
On 2022-10-27 08:31, William Edwards wrote: Op 27 okt. 2022 om 04:25 heeft Timo Sirainen het volgende geschreven: Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with: * Database (sql/ldap/whatever) containing user -> backend table. * Configure Dovecot proxy to use this database as passdb. * For HA change dovemon to update the database if backend is down to move users elsewhere * When backend comes up, move users into it. Set delay_until extra field for user in passdb to 5 seconds into future and kick the user in its old backend (e.g. via doveadm HTTP API). All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director. This is my train of thought as well. I believe the following would suffice for most setups. A database with: - Current vhost count per backend server. Alternatively, count the temporary user mappings. - Backend servers. - Temporary user mappings between user - backend server. This database is accessible by all Dovecot proxies in case there’s multiple. Steps when receiving a login: - Check if a temporary user mapping exists. - If so, proxy to the backend server in the temporary mapping. (To do: clean up mappings.) - If not, pick the backend server with the lowest vhost count, create a temporary mapping, then increase the vhost count of the chosen backend server. A monitoring service up/downs backend servers. E.g. by checking the port that we proxy to for each backend server. When a backend server is set to down, kick the user to force a reconnection. (Is that how Director ‘moves’ users?) Here is my alternative input as well using database cluster/file. Create connection mappings table in database cluster where each row must be containing user id, backend id and frontend id and agent hash, alternatively mappings file containing such info and synced across all servers. Incorporate multiple simultaneous mappings using agent hash which can be useful e.g. in the event of using client apps from several devices, in the IMAP proxy perhaps update the first row agent hash which doesnt have hash and matching frontend and user id in post login requests. Create service in each backend, monitoring login and logout entries, and whenever there is one, add the relevant user and frontend row in mappings table/file. In the event of remove just mark one matching entry with exclusion to unknown agent hash as soft removed. In load balancing solution, for SMTP/IMAP connections, use perhaps a lua script, to check mappings in database or file, and find which backend user was logged to, and alongside generate user agent hash perhaps using base64 encoding to locate exact client connection backend row in mappings where several entries might be present, and proxy the incoming request to it, uncheck soft removed if same backend using same user agent hash, if there is no mappings, use the normal load balancing method which in post login requests its mappings will be automatically created. Zakaria.
Re: The end of Dovecot Director?
On 2022-10-27 08:31, William Edwards wrote: Op 27 okt. 2022 om 04:25 heeft Timo Sirainen het volgende geschreven: Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with: * Database (sql/ldap/whatever) containing user -> backend table. * Configure Dovecot proxy to use this database as passdb. * For HA change dovemon to update the database if backend is down to move users elsewhere * When backend comes up, move users into it. Set delay_until extra field for user in passdb to 5 seconds into future and kick the user in its old backend (e.g. via doveadm HTTP API). All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director. This is my train of thought as well. I believe the following would suffice for most setups. A database with: - Current vhost count per backend server. Alternatively, count the temporary user mappings. - Backend servers. - Temporary user mappings between user - backend server. This database is accessible by all Dovecot proxies in case there’s multiple. Steps when receiving a login: - Check if a temporary user mapping exists. - If so, proxy to the backend server in the temporary mapping. (To do: clean up mappings.) - If not, pick the backend server with the lowest vhost count, create a temporary mapping, then increase the vhost count of the chosen backend server. A monitoring service up/downs backend servers. E.g. by checking the port that we proxy to for each backend server. When a backend server is set to down, kick the user to force a reconnection. (Is that how Director ‘moves’ users?) Here is my alternative input as well using database cluster/file. Create connection mappings table in database cluster where each row must be containing user id, backend id and frontend id and agent hash, alternatively mappings file containing such info and synced across all servers. Incorporate multiple simultaneous mappings using agent hash which can be useful e.g. in the event of using client apps from several devices, in the IMAP proxy perhaps update the first row agent hash which doesnt have hash and matching frontend and user id in post login requests. Create service in each backend, monitoring login and logout entries, and whenever there is one, add the relevant user and frontend row in mappings table/file. In the event of remove just mark one matching entry with exclusion to unknown agent hash as soft removed. In load balancing solution, for SMTP/IMAP connections, use perhaps a lua script, to check mappings in database or file, and find which backend user was logged to, and alongside generate user agent hash perhaps using base64 encoding to locate exact client connection backend row in mappings where several entries might be present, and proxy the incoming request to it, uncheck soft removed if same backend using same user agent hash, if there is no mappings, use the normal load balancing method which in post login requests its mappings will be automatically created. Zakaria.
Re: The end of Dovecot Director?
> Op 27 okt. 2022 om 04:25 heeft Timo Sirainen het volgende > geschreven: > > Director never worked especially well, and for most use cases it's just > unnecessarily complex. I think usually it could be replaced with: > > * Database (sql/ldap/whatever) containing user -> backend table. > * Configure Dovecot proxy to use this database as passdb. > * For HA change dovemon to update the database if backend is down to move > users elsewhere > * When backend comes up, move users into it. Set delay_until extra field for > user in passdb to 5 seconds into future and kick the user in its old backend > (e.g. via doveadm HTTP API). > > All this can be done with existing Dovecot. Should be much easier to build a > project doing this than forking director. This is my train of thought as well. I believe the following would suffice for most setups. A database with: - Current vhost count per backend server. Alternatively, count the temporary user mappings. - Backend servers. - Temporary user mappings between user - backend server. This database is accessible by all Dovecot proxies in case there’s multiple. Steps when receiving a login: - Check if a temporary user mapping exists. - If so, proxy to the backend server in the temporary mapping. (To do: clean up mappings.) - If not, pick the backend server with the lowest vhost count, create a temporary mapping, then increase the vhost count of the chosen backend server. A monitoring service up/downs backend servers. E.g. by checking the port that we proxy to for each backend server. When a backend server is set to down, kick the user to force a reconnection. (Is that how Director ‘moves’ users?)
Re: The end of Dovecot Director?
Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with: * Database (sql/ldap/whatever) containing user -> backend table. * Configure Dovecot proxy to use this database as passdb. * For HA change dovemon to update the database if backend is down to move users elsewhere * When backend comes up, move users into it. Set delay_until extra field for user in passdb to 5 seconds into future and kick the user in its old backend (e.g. via doveadm HTTP API). All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director.
Re: The end of Dovecot Director?
Am 2022-10-26 11:52, schrieb Maciej Milaszewski: Will there be a fork dovecot ? Hm, maybe it would be possible to just fork the director component? But it would still require a passionate C developer. Whether LibreCot or FreeDirector will be born... I'd be happy to support both! And don't feel obligated to use these names ;) Ciao - Frank
Re: The end of Dovecot Director?
Maciej Milaszewski schreef op 2022-10-26 11:52: Hi What is the planned replacement like doveadm director status move / kick / flush add /up / del In 3.0 ? This question has been answered in the thread. Will there be a fork dovecot ? If we, the community, start one, yes. -- With kind regards, William Edwards
Re: The end of Dovecot Director?
Hi What is the planned replacement like doveadm director status move / kick / flush add /up / del In 3.0 ? Will there be a fork dovecot ? OpenPGP_signature Description: OpenPGP digital signature
Re: The end of Dovecot Director?
> On 26/10/2022 12:42 EEST Narcis Garcia wrote: > > > El 26/10/22 a les 10:51, Aki Tuomi ha escrit: > > > >> On 26/10/2022 11:41 EEST Narcis Garcia wrote: > >> > >> > >> El 26/10/22 a les 10:29, MK ha escrit: > To be clear, we are not removing proxying features from Dovecot either. > Just the director ring feature. > >>> To be realy clear, you are not removing the proxy feature in dovecot that > >>> can be used to proxy users to different backend server on which > >>> the users mailboxes are stored? > >>> > >>> Thanks Oliver > >>> > >> > >> Does this removal include or exclude IMAP backends? > >> > >> -- > >> > >> Narcis Garcia > >> > > > > > > No. The only thing removed is the director component. Proxying works, IMAP > > backends are not removed. Director is responsible for mapping users to > > particular hosts. > > > > This change will affect mostly people with more than 1-2 backends, with 2 > > backends you can still have primary/backup setup. Dovecot will still > > happily proxy connections to your backends. > > > > AKi > > > Mmhh what about this for same FQDN? > o...@example.net -> local Dovecot mailbox > t...@example.net -> local Dovecot mailbox > th...@example.net -> Specific IMAP backend > f...@example.net -> local Dovecot mailbox > > -- > > Narcis Garcia Still gonna work. Aki
Re: The end of Dovecot Director?
El 26/10/22 a les 10:51, Aki Tuomi ha escrit: On 26/10/2022 11:41 EEST Narcis Garcia wrote: El 26/10/22 a les 10:29, MK ha escrit: To be clear, we are not removing proxying features from Dovecot either. Just the director ring feature. To be realy clear, you are not removing the proxy feature in dovecot that can be used to proxy users to different backend server on which the users mailboxes are stored? Thanks Oliver Does this removal include or exclude IMAP backends? -- Narcis Garcia No. The only thing removed is the director component. Proxying works, IMAP backends are not removed. Director is responsible for mapping users to particular hosts. This change will affect mostly people with more than 1-2 backends, with 2 backends you can still have primary/backup setup. Dovecot will still happily proxy connections to your backends. AKi Mmhh what about this for same FQDN? o...@example.net -> local Dovecot mailbox t...@example.net -> local Dovecot mailbox th...@example.net -> Specific IMAP backend f...@example.net -> local Dovecot mailbox -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: The end of Dovecot Director?
> On 26/10/2022 11:41 EEST Narcis Garcia wrote: > > > El 26/10/22 a les 10:29, MK ha escrit: > >> To be clear, we are not removing proxying features from Dovecot either. > >> Just the director ring feature. > > To be realy clear, you are not removing the proxy feature in dovecot that > > can be used to proxy users to different backend server on which > > the users mailboxes are stored? > > > > Thanks Oliver > > > > Does this removal include or exclude IMAP backends? > > -- > > Narcis Garcia > No. The only thing removed is the director component. Proxying works, IMAP backends are not removed. Director is responsible for mapping users to particular hosts. This change will affect mostly people with more than 1-2 backends, with 2 backends you can still have primary/backup setup. Dovecot will still happily proxy connections to your backends. AKi
Re: The end of Dovecot Director?
El 26/10/22 a les 10:29, MK ha escrit: To be clear, we are not removing proxying features from Dovecot either. Just the director ring feature. To be realy clear, you are not removing the proxy feature in dovecot that can be used to proxy users to different backend server on which the users mailboxes are stored? Thanks Oliver Does this removal include or exclude IMAP backends? -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
AW: The end of Dovecot Director?
>To be clear, we are not removing proxying features from Dovecot either. Just >the director ring feature. To be realy clear, you are not removing the proxy feature in dovecot that can be used to proxy users to different backend server on which the users mailboxes are stored? Thanks Oliver >Aki > On 21/10/2022 14:14 EEST Amol Kulkarni wrote: > > > Nginx has an mail proxy for pop, imap, smtp. > Can it be used instead of director ? > > > On Fri, 21 Oct 2022 at 16:21, wrote: > > On 2022-10-21 10:51, Zhang Huangbin wrote: > > >> On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: > > >> > > >> I was wondering if one can achieve the same implementation with > > >> haproxy without dovecot director? > > > > > > The most important part of Director is it makes sure same mail > > user > always proxied to same backend IMAP server. > > > > > > If mailbox is in Maildir format (and stored on shared storage > > like > NFS), accessing it from different server may corrupt Dovecot > > index > files and mailbox becomes unaccessible. Director perfectly > > avoids this > issue. > > > > > > HAProxy can proxy mail user from same client IP to same backend > > IMAP > server, but not same mail user from different IPs. > > > > > > Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): > > > > > > "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a > > > temporary user -> mail server mapping. As long as user has > > simultaneous > connections, the user is always redirected to the > > same server. Each > proxy server is running its own director > > process, and the directors are > communicating the state to each > > others. Directors are mainly useful for > setups where all of the > > mail storage is seen by all servers, such as > with NFS or a cluster > > filesystem." > > > > > > > > > Zhang Huangbin, founder of: > > > - iRedMail: Open source email server solution: > > > https://www.iredmail.org/ > > > - Spider: Lightweight, on-premises Email Archiving Software: > > > https://spiderd.io > > > > Aha makes sense, although I was not able to see how can index files > > be corrupted when its if will going to be updated, its in same > > manner as from different connection, e.g. opening email account > > from different app clients, with different connections, does not corrupt > > the index files? > > > > Also, Is it the issue Director resolving as well its with > > maintaining the logged in dovecot connection to same backend? > > Anyhow, thanks for your valuable efforts in clearing this :) > > > > I wondered if there is any other solution to avoid corrupting index > > files? Perhaps if dovecot offer database indexing as well as login > > sessions, it seems that this would eliminate Director requirement, > > and offer better high availability, as for now userdb/authdb is > > only available per my knowledge, and using database cluster > > resolves the issue with user and auth queries during simultaneous > > connections to a different backends. > > > > Otherwise, it seems in large enterprise deployment with high > > availability a Director implementation will be needed, hopefully we > > will find an alternative solution by the time Dovecot 3 is released. > > > > I might need to get my head around building dovecot with customised > > modules and review the code which was removed and return it back, if > > anyone is planning to this, and well off ahead of me, please let me > > know, we might be able to help one another. > > > > With thanks. > > > > Zakaria. > >
Re: The end of Dovecot Director?
On 2022-10-21 13:25, dove...@ptld.com wrote: the problem that prevents most load balancers from handling the backend imap/pop traffic is that the load balancer needs to be aware of the context of each connection. which all boils down to the index files (only a single dovecot server can access a set of index files concurrently, else the indexes will get corrupted) As someone else asked on this thread, what prevents two clients, both being directed to the same server, from fighting over index files? Wouldn't file locks over NFS prevent this problem? And if so, doesn't that also prevent two dovecot installations from fighting over index files? i believe the dovecot processes have some sort of interprocess communication when they are running on the same host that they use to negotiate writes to the index files. i don't really know the details, other than that the index files get corrupted very quickly if multiple hosts are accessing them at once. the index files are fine if a users' multiple imap sessions are on a single host. iirc, dovecot does use file locks when moving/deleting maildir+ message files. but that's not really the issue - it's all about the index files. those index files just weren't designed to have parallel access from multiple machines. What is a way to test your system to know if dovecot is using the default fcntl file locks over NFS4 and they actually work? Or is it better/safer to use dotlock on NFS4 without director? nfs locks do work, as long as your nfs server supports them well. dotlocks don't require any nfs server support, but they are slower. but, for the most part if you are redirecting users sessions to the same server it doesn't matter. we've used both locking types, though dotlocks were more reliable on some nfs servers. as long as you aren't using DBOX for mail storage, having the indexes get corrupted isn't the end of the world - dovecot will just regenerate them (though you might have to remove the broken files and kill the users' sessions to force this). there's some dovecot documentation with suggestions: https://doc.dovecot.org/configuration_manual/nfs/ and some older docs: https://wiki1.dovecot.org/NFS
Re: The end of Dovecot Director?
On 2022-10-24, Alessio Cecchi wrote: > > Director is not only used by large companies but also in small > installations consisting of 2 servers and cannot be immediately replaced > with Nginx as it has to manage the user/backend association for POP, > IMAP, LMTP, Managesieve. For the small multi-server installations I've done I have used ldap (though another db would work) where a primary server is defined for each user. The MTA does a lookup and uses the relevant host as destination for LMTP delivery. For client connections, users can connect to any server; Dovecot config uses proxy_maybe so if they hit the primary server for their mailbox then it's served directly, and otherwise it's proxied. (And in my case I care more about availability than splitting disk storage, so I replicate in Dovecot). This doesn't use Director. Isn't Director only really useful in the case where you have 2 or more servers *and shared mailbox storage*, and you don't have a way to define a "primary" server for the mailbox? I don't really see how it's useful for simpler configs.
Re: The end of Dovecot Director?
On 2022-10-21 11:38, Heiko Schlittermann wrote: Apparently, Dovecot Director is going to be removed in the next major version of Dovecot and the commercial Dovecot cluster architecture will be its successor: We - the communitiy - are free to continue development of the director. So, who's going to fork dovecot (director)? Ciao - Frank
Re: The end of Dovecot Director?
On 2022-10-21 10:54, Zhang Huangbin wrote: On Oct 21, 2022, at 5:51 PM, Zhang Huangbin wrote: If mailbox is in Maildir format (and stored on shared storage like NFS), accessing it from different server may corrupt Dovecot index files and mailbox becomes unaccessible. Director perfectly avoids this issue. To be clear: Accessing same mailbox from different IMAP servers __at the same time__. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io Thanks :)
Re: The end of Dovecot Director?
the problem that prevents most load balancers from handling the backend imap/pop traffic is that the load balancer needs to be aware of the context of each connection. which all boils down to the index files (only a single dovecot server can access a set of index files concurrently, else the indexes will get corrupted) As someone else asked on this thread, what prevents two clients, both being directed to the same server, from fighting over index files? Wouldn't file locks over NFS prevent this problem? And if so, doesn't that also prevent two dovecot installations from fighting over index files? What is a way to test your system to know if dovecot is using the default fcntl file locks over NFS4 and they actually work? Or is it better/safer to use dotlock on NFS4 without director?
Re: The end of Dovecot Director?
I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. Curious, trying to understand.. Why would not a true load balancer not be an attractive option for those that need to load balance services across multiple front ends? It is the model we use with most of our ISP's and scales very well. The choice of load balancer is important, but with HA load balancers, you are assured that you don't have a single point of failure, and you can spread loads more granularly, eg POP, IMAP and other services. Not to mention, you can use the same load balancer from many other traffic shaping solutions. the problem that prevents most load balancers from handling the backend imap/pop traffic is that the load balancer needs to be aware of the context of each connection. which all boils down to the index files (only a single dovecot server can access a set of index files concurrently, else the indexes will get corrupted) in more usual HTTP case, you'd probably use some sort of cookie based session affinity to keep connections from a particular user going to the same backend http server. but in the IMAP/POP case most load balancers don't really know anything about the connection and are just blindly forwarding them to the backend nodes. director (or the custom nginx LB setups) get to handle part of the IMAP/POP transaction and get a bit of context (knowing which user the connection is for) to then make additional decisions about which backend imap node to send the connection through to (preventing the index corruption problem). you could use IP based affinity on pop/imap connections for a context-unaware load balancer, but if you end up with a lot of NAT users your connections will end up being unbalanced across the backend servers. and connections from something like a webmail server will all end up going to the same backend server (since they'd all come from the same IP address). you could also just have a dumb load balancer sitting in front and just randomly sending the connections to any backend imap server, but each backend imap server would have to maintain its own copy of the indexes. workable, but not particularly efficient, especially if you have large a large number of backend imap servers (though, with a small setup with only 2 or 3 backend imap servers for redundancy instead of performance, probably acceptable) you'd still want some sort of load balanced director or nginx pool as well, in order to handle redundancy at that level. but that's a much easier task, as you don't have to worry about the session context at that point. (we have hardware load balancers in front of the director nodes)
Re: The end of Dovecot Director?
> Op 21 okt. 2022 om 19:42 heeft Brendan Braybrook het
> volgende geschreven:
>
> On 2022-10-21 04:29, spi wrote:
>>> Am 21.10.22 um 13:14 schrieb Amol Kulkarni:
>>> Nginx has an mail proxy for pop, imap, smtp.
>>> Can it be used instead of director ?
>> Nginx can authenticate imap/smtp (and probably pop3) users. If you that, you
>> can define a backend server the session is routed to. Currently I use that
>> approach to authenticate users by client certificates and route them to the
>> appriopriate backend (well, I only have one ;-).
>
> we've recently switched to director, but we used to use nginx for this as
> well (we started using nginx before director existed). if you load balance
> the nginx proxies themselves, you can easily handle hundreds of thousands of
> concurrent imap connections with them.
>
> in debian/ubuntu, i don't think the nginx packages include the mail proxy
> bits. iirc, we had to compile nginx ourselves with the mail proxy bits
> included.
>
> the nginx config is pretty simple, you have to pre-specifiy the capabilities
> for each protocol and set up some sort of way for nginx to auth and get which
> backend node to send to as spi notes (in this example, it's an http call):
>
> mail {
> auth_http localhost:8080/cgi-bin/auth;
> proxy_pass_error_message on;
>
> pop3_capabilities "TOP" "UIDL" "RESP-CODES" "PIPELINING" "AUTH-RESP-CODE"
> "USER" "SASL PLAIN" "SASL PLAIN LOGIN";
> server {
>listen 110;
>protocol pop3;
>proxyon;
> }
>
> imap_capabilities "IMAP4rev1" "LITERAL+" "SASL-IR" "LOGIN-REFERRALS" "IDLE";
> server {
>listen 143;
>protocol imap;
>proxyon;
> }
> }
>
> localhost:8080/cgi-bin/auth then just auths the user/pass that nginx gets
> from the incoming request and returns success and the next hop for nginx to
> proxy to.
>
> the only real difficulty is that you then need to write your own state system
> into your cgi auth script to ensure that users get sent to the same backend
> imap server if they already have an existing connection and have some way to
> safely fail over to other backend imap servers should one go down. (it's nice
> to have director handle this state stuff for you)
Although Director does not do health checks and down servers automatically. I
was working on an open source program for that (as an alternative to Dovemon),
but that plan is canceled with this announcement :)
Re: The end of Dovecot Director?
On 2022-10-21 04:29, spi wrote:
Am 21.10.22 um 13:14 schrieb Amol Kulkarni:
Nginx has an mail proxy for pop, imap, smtp.
Can it be used instead of director ?
Nginx can authenticate imap/smtp (and probably pop3) users. If you that,
you can define a backend server the session is routed to. Currently I
use that approach to authenticate users by client certificates and route
them to the appriopriate backend (well, I only have one ;-).
we've recently switched to director, but we used to use nginx for this
as well (we started using nginx before director existed). if you load
balance the nginx proxies themselves, you can easily handle hundreds of
thousands of concurrent imap connections with them.
in debian/ubuntu, i don't think the nginx packages include the mail
proxy bits. iirc, we had to compile nginx ourselves with the mail proxy
bits included.
the nginx config is pretty simple, you have to pre-specifiy the
capabilities for each protocol and set up some sort of way for nginx to
auth and get which backend node to send to as spi notes (in this
example, it's an http call):
mail {
auth_http localhost:8080/cgi-bin/auth;
proxy_pass_error_message on;
pop3_capabilities "TOP" "UIDL" "RESP-CODES" "PIPELINING"
"AUTH-RESP-CODE" "USER" "SASL PLAIN" "SASL PLAIN LOGIN";
server {
listen 110;
protocol pop3;
proxyon;
}
imap_capabilities "IMAP4rev1" "LITERAL+" "SASL-IR" "LOGIN-REFERRALS"
"IDLE";
server {
listen 143;
protocol imap;
proxyon;
}
}
localhost:8080/cgi-bin/auth then just auths the user/pass that nginx
gets from the incoming request and returns success and the next hop for
nginx to proxy to.
the only real difficulty is that you then need to write your own state
system into your cgi auth script to ensure that users get sent to the
same backend imap server if they already have an existing connection and
have some way to safely fail over to other backend imap servers should
one go down. (it's nice to have director handle this state stuff for you)
Re: The end of Dovecot Director?
Nginx is an excellent suggestion for the purpose. However I do not like German client certificates. That is far too much "proof" of identification 18/21++ on a public network with nowhere to hide and those of us who are not German citizens and do not have the advantage of a friendly local police jurisdiction with massive international clout and an assumed legitimacy for all the online surveillance, policing, and copping with unfounded sex charges etc. being pressed online. Not that I care much for alcohol, but the analogy that comes to mind with such "proof" of identity presented across the internet as a public certificate is that of "public drunkenness," versus, say, "drinking privately in one's quarters," i.e., making an encrypted connection, and only then within the encrypted channel establishing identity and authorization with a username and password or other means of authentication. On Friday, October 21, 2022 3:29:36 AM AKDT, spi wrote: Am 21.10.22 um 13:14 schrieb Amol Kulkarni: Nginx has an mail proxy for pop, imap, smtp. Can it be used instead of director ? Nginx can authenticate imap/smtp (and probably pop3) users. If you that, you can define a backend server the session is routed to. Currently I use that approach to authenticate users by client certificates and route them to the appriopriate backend (well, I only have one ;-). -- Cheers spi
Re: The end of Dovecot Director?
On 2022-10-20 22:19, Zhang Huangbin wrote: On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: My understanding is that Director is targeted toward large enterprise mail installations that will incorporate several servers for a given function. In such an environment, Director would be the fore-person\traffic-cop keeping things organized & squared-away. Director is used when you setup frontend servers in a load-balance cluster, proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io Curious, trying to understand.. Why would not a true load balancer not be an attractive option for those that need to load balance services across multiple front ends? It is the model we use with most of our ISP's and scales very well. The choice of load balancer is important, but with HA load balancers, you are assured that you don't have a single point of failure, and you can spread loads more granularly, eg POP, IMAP and other services. Not to mention, you can use the same load balancer from many other traffic shaping solutions. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
Re: The end of Dovecot Director?
To be clear, you are removing the Director... --- Tom On 2022-10-21 13:28, Aki Tuomi wrote: To be clear, we are not removing proxying features from Dovecot either. Just the director ring feature. Aki On 21/10/2022 14:14 EEST Amol Kulkarni wrote: Nginx has an mail proxy for pop, imap, smtp. Can it be used instead of director ? On Fri, 21 Oct 2022 at 16:21, wrote: > On 2022-10-21 10:51, Zhang Huangbin wrote: > >> On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: > >> > >> I was wondering if one can achieve the same implementation with > >> haproxy without dovecot director? > > > > The most important part of Director is it makes sure same mail user > > always proxied to same backend IMAP server. > > > > If mailbox is in Maildir format (and stored on shared storage like > > NFS), accessing it from different server may corrupt Dovecot index > > files and mailbox becomes unaccessible. Director perfectly avoids this > > issue. > > > > HAProxy can proxy mail user from same client IP to same backend IMAP > > server, but not same mail user from different IPs. > > > > Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): > > > > "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a > > temporary user -> mail server mapping. As long as user has simultaneous > > connections, the user is always redirected to the same server. Each > > proxy server is running its own director process, and the directors are > > communicating the state to each others. Directors are mainly useful for > > setups where all of the mail storage is seen by all servers, such as > > with NFS or a cluster filesystem." > > > > > > Zhang Huangbin, founder of: > > - iRedMail: Open source email server solution: > > https://www.iredmail.org/ > > - Spider: Lightweight, on-premises Email Archiving Software: > > https://spiderd.io > > Aha makes sense, although I was not able to see how can index files be > corrupted when its if will going to be updated, its in same manner as > from different connection, e.g. opening email account from different app > clients, with different connections, does not corrupt the index files? > > Also, Is it the issue Director resolving as well its with maintaining > the logged in dovecot connection to same backend? Anyhow, thanks for > your valuable efforts in clearing this :) > > I wondered if there is any other solution to avoid corrupting index > files? Perhaps if dovecot offer database indexing as well as login > sessions, it seems that this would eliminate Director requirement, and > offer better high availability, as for now userdb/authdb is only > available per my knowledge, and using database cluster resolves the > issue with user and auth queries during simultaneous connections to a > different backends. > > Otherwise, it seems in large enterprise deployment with high > availability a Director implementation will be needed, hopefully we will > find an alternative solution by the time Dovecot 3 is released. > > I might need to get my head around building dovecot with customised > modules and review the code which was removed and return it back, if > anyone is planning to this, and well off ahead of me, please let me > know, we might be able to help one another. > > With thanks. > > Zakaria. >
Re: The end of Dovecot Director?
Am 21.10.22 um 13:14 schrieb Amol Kulkarni: Nginx has an mail proxy for pop, imap, smtp. Can it be used instead of director ? Nginx can authenticate imap/smtp (and probably pop3) users. If you that, you can define a backend server the session is routed to. Currently I use that approach to authenticate users by client certificates and route them to the appriopriate backend (well, I only have one ;-). -- Cheers spi
Re: The end of Dovecot Director?
To be clear, we are not removing proxying features from Dovecot either. Just the director ring feature. Aki > On 21/10/2022 14:14 EEST Amol Kulkarni wrote: > > > Nginx has an mail proxy for pop, imap, smtp. > Can it be used instead of director ? > > > On Fri, 21 Oct 2022 at 16:21, wrote: > > On 2022-10-21 10:51, Zhang Huangbin wrote: > > >> On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: > > >> > > >> I was wondering if one can achieve the same implementation with > > >> haproxy without dovecot director? > > > > > > The most important part of Director is it makes sure same mail user > > > always proxied to same backend IMAP server. > > > > > > If mailbox is in Maildir format (and stored on shared storage like > > > NFS), accessing it from different server may corrupt Dovecot index > > > files and mailbox becomes unaccessible. Director perfectly avoids this > > > issue. > > > > > > HAProxy can proxy mail user from same client IP to same backend IMAP > > > server, but not same mail user from different IPs. > > > > > > Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): > > > > > > "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a > > > temporary user -> mail server mapping. As long as user has simultaneous > > > connections, the user is always redirected to the same server. Each > > > proxy server is running its own director process, and the directors are > > > communicating the state to each others. Directors are mainly useful for > > > setups where all of the mail storage is seen by all servers, such as > > > with NFS or a cluster filesystem." > > > > > > > > > Zhang Huangbin, founder of: > > > - iRedMail: Open source email server solution: > > > https://www.iredmail.org/ > > > - Spider: Lightweight, on-premises Email Archiving Software: > > > https://spiderd.io > > > > Aha makes sense, although I was not able to see how can index files be > > corrupted when its if will going to be updated, its in same manner as > > from different connection, e.g. opening email account from different app > > clients, with different connections, does not corrupt the index files? > > > > Also, Is it the issue Director resolving as well its with maintaining > > the logged in dovecot connection to same backend? Anyhow, thanks for > > your valuable efforts in clearing this :) > > > > I wondered if there is any other solution to avoid corrupting index > > files? Perhaps if dovecot offer database indexing as well as login > > sessions, it seems that this would eliminate Director requirement, and > > offer better high availability, as for now userdb/authdb is only > > available per my knowledge, and using database cluster resolves the > > issue with user and auth queries during simultaneous connections to a > > different backends. > > > > Otherwise, it seems in large enterprise deployment with high > > availability a Director implementation will be needed, hopefully we will > > find an alternative solution by the time Dovecot 3 is released. > > > > I might need to get my head around building dovecot with customised > > modules and review the code which was removed and return it back, if > > anyone is planning to this, and well off ahead of me, please let me > > know, we might be able to help one another. > > > > With thanks. > > > > Zakaria. > >
Re: The end of Dovecot Director?
Nginx has an mail proxy for pop, imap, smtp. Can it be used instead of director ? On Fri, 21 Oct 2022 at 16:21, wrote: > On 2022-10-21 10:51, Zhang Huangbin wrote: > >> On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: > >> > >> I was wondering if one can achieve the same implementation with > >> haproxy without dovecot director? > > > > The most important part of Director is it makes sure same mail user > > always proxied to same backend IMAP server. > > > > If mailbox is in Maildir format (and stored on shared storage like > > NFS), accessing it from different server may corrupt Dovecot index > > files and mailbox becomes unaccessible. Director perfectly avoids this > > issue. > > > > HAProxy can proxy mail user from same client IP to same backend IMAP > > server, but not same mail user from different IPs. > > > > Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): > > > > "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a > > temporary user -> mail server mapping. As long as user has simultaneous > > connections, the user is always redirected to the same server. Each > > proxy server is running its own director process, and the directors are > > communicating the state to each others. Directors are mainly useful for > > setups where all of the mail storage is seen by all servers, such as > > with NFS or a cluster filesystem." > > > > > > Zhang Huangbin, founder of: > > - iRedMail: Open source email server solution: > > https://www.iredmail.org/ > > - Spider: Lightweight, on-premises Email Archiving Software: > > https://spiderd.io > > Aha makes sense, although I was not able to see how can index files be > corrupted when its if will going to be updated, its in same manner as > from different connection, e.g. opening email account from different app > clients, with different connections, does not corrupt the index files? > > Also, Is it the issue Director resolving as well its with maintaining > the logged in dovecot connection to same backend? Anyhow, thanks for > your valuable efforts in clearing this :) > > I wondered if there is any other solution to avoid corrupting index > files? Perhaps if dovecot offer database indexing as well as login > sessions, it seems that this would eliminate Director requirement, and > offer better high availability, as for now userdb/authdb is only > available per my knowledge, and using database cluster resolves the > issue with user and auth queries during simultaneous connections to a > different backends. > > Otherwise, it seems in large enterprise deployment with high > availability a Director implementation will be needed, hopefully we will > find an alternative solution by the time Dovecot 3 is released. > > I might need to get my head around building dovecot with customised > modules and review the code which was removed and return it back, if > anyone is planning to this, and well off ahead of me, please let me > know, we might be able to help one another. > > With thanks. > > Zakaria. >
Re: The end of Dovecot Director?
On 2022-10-21 10:51, Zhang Huangbin wrote: On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: I was wondering if one can achieve the same implementation with haproxy without dovecot director? The most important part of Director is it makes sure same mail user always proxied to same backend IMAP server. If mailbox is in Maildir format (and stored on shared storage like NFS), accessing it from different server may corrupt Dovecot index files and mailbox becomes unaccessible. Director perfectly avoids this issue. HAProxy can proxy mail user from same client IP to same backend IMAP server, but not same mail user from different IPs. Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a temporary user -> mail server mapping. As long as user has simultaneous connections, the user is always redirected to the same server. Each proxy server is running its own director process, and the directors are communicating the state to each others. Directors are mainly useful for setups where all of the mail storage is seen by all servers, such as with NFS or a cluster filesystem." Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io Aha makes sense, although I was not able to see how can index files be corrupted when its if will going to be updated, its in same manner as from different connection, e.g. opening email account from different app clients, with different connections, does not corrupt the index files? Also, Is it the issue Director resolving as well its with maintaining the logged in dovecot connection to same backend? Anyhow, thanks for your valuable efforts in clearing this :) I wondered if there is any other solution to avoid corrupting index files? Perhaps if dovecot offer database indexing as well as login sessions, it seems that this would eliminate Director requirement, and offer better high availability, as for now userdb/authdb is only available per my knowledge, and using database cluster resolves the issue with user and auth queries during simultaneous connections to a different backends. Otherwise, it seems in large enterprise deployment with high availability a Director implementation will be needed, hopefully we will find an alternative solution by the time Dovecot 3 is released. I might need to get my head around building dovecot with customised modules and review the code which was removed and return it back, if anyone is planning to this, and well off ahead of me, please let me know, we might be able to help one another. With thanks. Zakaria.
Re: The end of Dovecot Director?
> On Oct 21, 2022, at 5:51 PM, Zhang Huangbin wrote: > > If mailbox is in Maildir format (and stored on shared storage like NFS), > accessing it from different server may corrupt Dovecot index files and > mailbox becomes unaccessible. Director perfectly avoids this issue. To be clear: Accessing same mailbox from different IMAP servers __at the same time__. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io
Re: The end of Dovecot Director?
> On Oct 21, 2022, at 5:23 PM, hi@zakaria.website wrote: > > I was wondering if one can achieve the same implementation with haproxy > without dovecot director? The most important part of Director is it makes sure same mail user always proxied to same backend IMAP server. If mailbox is in Maildir format (and stored on shared storage like NFS), accessing it from different server may corrupt Dovecot index files and mailbox becomes unaccessible. Director perfectly avoids this issue. HAProxy can proxy mail user from same client IP to same backend IMAP server, but not same mail user from different IPs. Quote (https://doc.dovecot.org/admin_manual/director/dovecotdirector/): "Director can be used by Dovecot’s IMAP/POP3/LMTP proxy to keep a temporary user -> mail server mapping. As long as user has simultaneous connections, the user is always redirected to the same server. Each proxy server is running its own director process, and the directors are communicating the state to each others. Directors are mainly useful for setups where all of the mail storage is seen by all servers, such as with NFS or a cluster filesystem." Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io
Re: The end of Dovecot Director?
Steff Majeur (Do 20 Okt 2022 11:24:49 CEST):
> I recently stumbled upon the following commit on the Dovecot core Github
> repository:
> https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d357323005358
>
> Apparently, Dovecot Director is going to be removed in the next major version
> of Dovecot and the commercial Dovecot cluster architecture will be its
> successor:
> https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c25f004e46720/source/admin_manual/cluster/index.rst
>
> This would be a huge blow for many organizations around the world that are
> currently using Dovecot with Director in a shared storage environment.
We - the communitiy - are free to continue development of the director.
Especially large organizations should re-think their ideas of getting
free software for free.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
signature.asc
Description: PGP signature
Re: The end of Dovecot Director?
On 2022-10-21 06:19, Zhang Huangbin wrote: On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: My understanding is that Director is targeted toward large enterprise mail installations that will incorporate several servers for a given function. In such an environment, Director would be the fore-person\traffic-cop keeping things organized & squared-away. Director is used when you setup frontend servers in a load-balance cluster, proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io Hi, I was wondering if one can achieve the same implementation with haproxy without dovecot director? Load balancing all requests to pop3, imap, managesieve and lmtp services from specified frontend servers i.e. webmail to specified backend servers and using NFS mount filesystem/syncing data across all servers to access emails with high availability? Not sure whats the big deal director is offering? Is it just a native functionality providing a feature to find which backend server have X emails available and chooses to load from e.g. its content i.e. like checks which first server that doesnt return http 404 response equivalent in IMAP/POP3/LMTP/ManageSieve? Sometime ago I used Varnish caching directors to implement high availability using 404 response status in http web server, and it seems great if we can have this feature in dovecot too, as it offers high availability with delayed-syncing/partial-syncing across unknown selected servers, I managed to use Varnish too in dovecot proxy service i.e. the webmail, yet it requires NFS mount or high available file system all servers can have through immediate access to e.g. maildir? Any helpful input that would clear the picture for me in regards dovecot director, would be ver much appreciated. With thanks. Zakaria.
RE: The end of Dovecot Director?
> servers. > > > > I setup load-balance cluster for clients with HAProxy + KeepAlived + > Dovecot Director running in frontend servers, so sad we have to find an > alternative to replace Director in such case. The code is still available you just need to build it yourself. I think they will develop a newer version, but maybe this 'older' module can be still used. > > > > It's not about "small/medium" servers, but the demand of > imap/pop3/lmtp proxy service, especially in load-balance cluster. > > I agree. I would even state that moving towards a containerized environment you do not have one huge server that does it all, but multiple sperate containers.
Re: The end of Dovecot Director?
El 21/10/22 a les 7:19, Zhang Huangbin ha escrit: On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: My understanding is that Director is targeted toward large enterprise mail installations that will incorporate several servers for a given function. In such an environment, Director would be the fore-person\traffic-cop keeping things organized & squared-away. Director is used when you setup frontend servers in a load-balance cluster, proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. It's used also to backend a 3rd party mailbox/IMAP for an account. -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: The end of Dovecot Director?
You still need in some sense one coherent file system to store and retrieve the mail messages. Although a load-balance cluster would still be quite useful for rejecting the bulk of unauthorized connections. I am sure in many cases a small/medium server can in fact sit and function quite adequately behind a large enterprise load balancing firewall and proxy, given the typical quantities of spam "out there" and the large number of bad connections typically attempted on any given system. On Thursday, October 20, 2022 9:19:59 PM AKDT, Zhang Huangbin wrote: On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: My understanding is that Director is targeted toward large enterprise mail installations that will incorporate several servers for a given function. In such an environment, Director would be the fore-person\traffic-cop keeping things organized & squared-away. Director is used when you setup frontend servers in a load-balance cluster, proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io
Re: The end of Dovecot Director?
Please post your solution. Sent from my iPhone - please excuse brevity and typos > On Oct 20, 2022, at 10:21 PM, Zhang Huangbin wrote: > > > >> On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: >> >> My understanding is that Director is targeted toward large enterprise mail >> installations that will incorporate several servers for a given function. In >> such an environment, Director would be the fore-person\traffic-cop keeping >> things organized & squared-away. > > Director is used when you setup frontend servers in a load-balance cluster, > proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. > > I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot > Director running in frontend servers, so sad we have to find an alternative > to replace Director in such case. > > It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy > service, especially in load-balance cluster. > > > Zhang Huangbin, founder of: > - iRedMail: Open source email server solution: https://www.iredmail.org/ > - Spider: Lightweight, on-premises Email Archiving Software: > https://spiderd.io > >
Re: The end of Dovecot Director?
> On Oct 21, 2022, at 4:19 AM, Antonio Leding wrote: > > My understanding is that Director is targeted toward large enterprise mail > installations that will incorporate several servers for a given function. In > such an environment, Director would be the fore-person\traffic-cop keeping > things organized & squared-away. Director is used when you setup frontend servers in a load-balance cluster, proxy imap/pop3/lmtp/managesieve requests to backend Dovecot servers. I setup load-balance cluster for clients with HAProxy + KeepAlived + Dovecot Director running in frontend servers, so sad we have to find an alternative to replace Director in such case. It's not about "small/medium" servers, but the demand of imap/pop3/lmtp proxy service, especially in load-balance cluster. Zhang Huangbin, founder of: - iRedMail: Open source email server solution: https://www.iredmail.org/ - Spider: Lightweight, on-premises Email Archiving Software: https://spiderd.io
Re: The end of Dovecot Director?
My understanding is that Director is targeted toward large enterprise mail installations that will incorporate several servers for a given function. In such an environment, Director would be the fore-person\traffic-cop keeping things organized & squared-away. In other scenarios, the “pri\bu” means primary and backup DC instances which should be fine for many folks who just have a single server. Again this is my understanding so please feel free to correct me where I’m off-base… - - - On 20 Oct 2022, at 12:00, Steve Litt wrote: Aki Tuomi said on Thu, 20 Oct 2022 21:41:53 +0300 (EEST) Most small/medium servers do not need director. You can use replicator get a pri/bu pair. I've never needed to use replicator. I don't even know what a pri/bu pair is. I just have fetchmail feed to procmail which delivers messages into my Dovecot maildir, and then access the Dovecot IMAP server with an email client. Hopefully I'll be able to continue doing it this way. Only the director part is being removed, rest of Dovecot remains. For the next major release we are also removing certain deprecated parts that have a replacement in elsewhere of the code. Is there a document on the deprecations and their replacements? I'd like to read it. The mail server functionality is going to remain 100% open source and free. The preceding sentence is a huge relief for me. Thanks! SteveT Steve Litt Summer 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: The end of Dovecot Director?
Aki Tuomi said on Thu, 20 Oct 2022 22:04:42 +0300 (EEST) >https://doc.dovecot.org/3.0/installation_guide/upgrading/from-2.3-to-3.0/ > >This is subject to change, as we have not actually released this >version yet. > >Aki Thanks Aki, I skimmed this document and it looks to me like nothing there applies to my Dovecot setup. I'll be checking it from time to time. Thanks, SteveT Steve Litt Summer 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: The end of Dovecot Director?
> On 20/10/2022 22:00 EEST Steve Litt wrote: > > > Aki Tuomi said on Thu, 20 Oct 2022 21:41:53 +0300 (EEST) > > >Most small/medium servers do not need director. You can use replicator > >get a pri/bu pair. > > I've never needed to use replicator. I don't even know what a pri/bu > pair is. I just have fetchmail feed to procmail which delivers messages > into my Dovecot maildir, and then access the Dovecot IMAP server with > an email client. Hopefully I'll be able to continue doing it this way. > > > > >Only the director part is being removed, rest of Dovecot remains. For > >the next major release we are also removing certain deprecated parts > >that have a replacement in elsewhere of the code. > > Is there a document on the deprecations and their replacements? I'd > like to read it. > > > > >The mail server functionality is going to remain 100% open source and > >free. > > The preceding sentence is a huge relief for me. Thanks! > > SteveT > https://doc.dovecot.org/3.0/installation_guide/upgrading/from-2.3-to-3.0/ This is subject to change, as we have not actually released this version yet. Aki
Re: The end of Dovecot Director?
Aki Tuomi said on Thu, 20 Oct 2022 21:41:53 +0300 (EEST) >Most small/medium servers do not need director. You can use replicator >get a pri/bu pair. I've never needed to use replicator. I don't even know what a pri/bu pair is. I just have fetchmail feed to procmail which delivers messages into my Dovecot maildir, and then access the Dovecot IMAP server with an email client. Hopefully I'll be able to continue doing it this way. > >Only the director part is being removed, rest of Dovecot remains. For >the next major release we are also removing certain deprecated parts >that have a replacement in elsewhere of the code. Is there a document on the deprecations and their replacements? I'd like to read it. > >The mail server functionality is going to remain 100% open source and >free. The preceding sentence is a huge relief for me. Thanks! SteveT Steve Litt Summer 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
RE: The end of Dovecot Director?
> Most small/medium servers do not need director. You can use replicator > get a pri/bu pair. > What is small?
Re: The end of Dovecot Director?
Most small/medium servers do not need director. You can use replicator get a pri/bu pair. Only the director part is being removed, rest of Dovecot remains. For the next major release we are also removing certain deprecated parts that have a replacement in elsewhere of the code. The mail server functionality is going to remain 100% open source and free. Aki > On 20/10/2022 21:37 EEST Steve Litt wrote: > > > I'm top posting because I can't make heads or tails of this thread. > Does this thread mean that Dovecot will no longer be Free Software? > > It appears that only Dovecot Director will be taken proprietary, but if > all of Dovecot is in jeopardy, I need to switch to another local IMAP > server program. Any suggestions will be welcome. > > Thanks, > > SteveT > > > Aki Tuomi said on Thu, 20 Oct 2022 13:02:38 +0300 (EEST) > > >> On 20/10/2022 12:24 EEST Steff Majeur > >> wrote: > >> > >> > >> I recently stumbled upon the following commit on the Dovecot core > >> Github repository: > >> https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d357323005358 > >> > >> Apparently, Dovecot Director is going to be removed in the next > >> major version of Dovecot and the commercial Dovecot cluster > >> architecture will be its successor: > >> https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c25f004e46720/source/admin_manual/cluster/index.rst > >> > > > >Yes, this is going to happen. > > > >> This would be a huge blow for many organizations around the world > >> that are currently using Dovecot with Director in a shared storage > >> environment. > >> > >> Can anyone of the Dovecot developers maybe enlighten us about the > >> future of Dovecot? > >> - Will there still be the Director feature in the next community > >> release of Dovecot? > > > >Next 2.3 CE release will have a director. > > > >> - If not, will there be a community feature that is on par with the > >> current Director feature? > > > >There will be more information about this closer to new major release, > >that we are working on. Director is still present in > >https://github.com/dovecot/core/tree/release-2.3 > > > >> - For how long will Dovecot version 2.3 still be supported (security > >> fixes, bug fixes)? Is there any EOL plan? > > > >This will be informed later, but as general rule, once we make a new > >major release, 2.3 will go into maintenance mode, and will receive > >only select bug fixes and CVE fixes. > > > >> Thanks for any clarification! > >> Steff > > > >Aki > > > SteveT > > Steve Litt > Summer 2022 featured book: Thriving in Tough Times > http://www.troubleshooters.com/bookstore/thrive.htm
Re: The end of Dovecot Director?
I'm top posting because I can't make heads or tails of this thread. Does this thread mean that Dovecot will no longer be Free Software? It appears that only Dovecot Director will be taken proprietary, but if all of Dovecot is in jeopardy, I need to switch to another local IMAP server program. Any suggestions will be welcome. Thanks, SteveT Aki Tuomi said on Thu, 20 Oct 2022 13:02:38 +0300 (EEST) >> On 20/10/2022 12:24 EEST Steff Majeur >> wrote: >> >> >> I recently stumbled upon the following commit on the Dovecot core >> Github repository: >> https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d357323005358 >> >> Apparently, Dovecot Director is going to be removed in the next >> major version of Dovecot and the commercial Dovecot cluster >> architecture will be its successor: >> https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c25f004e46720/source/admin_manual/cluster/index.rst >> > >Yes, this is going to happen. > >> This would be a huge blow for many organizations around the world >> that are currently using Dovecot with Director in a shared storage >> environment. >> >> Can anyone of the Dovecot developers maybe enlighten us about the >> future of Dovecot? >> - Will there still be the Director feature in the next community >> release of Dovecot? > >Next 2.3 CE release will have a director. > >> - If not, will there be a community feature that is on par with the >> current Director feature? > >There will be more information about this closer to new major release, >that we are working on. Director is still present in >https://github.com/dovecot/core/tree/release-2.3 > >> - For how long will Dovecot version 2.3 still be supported (security >> fixes, bug fixes)? Is there any EOL plan? > >This will be informed later, but as general rule, once we make a new >major release, 2.3 will go into maintenance mode, and will receive >only select bug fixes and CVE fixes. > >> Thanks for any clarification! >> Steff > >Aki SteveT Steve Litt Summer 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: The end of Dovecot Director?
> On 20/10/2022 12:24 EEST Steff Majeur wrote: > > > I recently stumbled upon the following commit on the Dovecot core Github > repository: > https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d357323005358 > > Apparently, Dovecot Director is going to be removed in the next major version > of Dovecot and the commercial Dovecot cluster architecture will be its > successor: > https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c25f004e46720/source/admin_manual/cluster/index.rst > Yes, this is going to happen. > This would be a huge blow for many organizations around the world that are > currently using Dovecot with Director in a shared storage environment. > > Can anyone of the Dovecot developers maybe enlighten us about the future of > Dovecot? > - Will there still be the Director feature in the next community release of > Dovecot? Next 2.3 CE release will have a director. > - If not, will there be a community feature that is on par with the current > Director feature? There will be more information about this closer to new major release, that we are working on. Director is still present in https://github.com/dovecot/core/tree/release-2.3 > - For how long will Dovecot version 2.3 still be supported (security fixes, > bug fixes)? Is there any EOL plan? > This will be informed later, but as general rule, once we make a new major release, 2.3 will go into maintenance mode, and will receive only select bug fixes and CVE fixes. > Thanks for any clarification! > Steff Aki
The end of Dovecot Director?
I recently stumbled upon the following commit on the Dovecot core Github repository: https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d357323005358 Apparently, Dovecot Director is going to be removed in the next major version of Dovecot and the commercial Dovecot cluster architecture will be its successor: https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c25f004e46720/source/admin_manual/cluster/index.rst This would be a huge blow for many organizations around the world that are currently using Dovecot with Director in a shared storage environment. Can anyone of the Dovecot developers maybe enlighten us about the future of Dovecot? - Will there still be the Director feature in the next community release of Dovecot? - If not, will there be a community feature that is on par with the current Director feature? - For how long will Dovecot version 2.3 still be supported (security fixes, bug fixes)? Is there any EOL plan? Thanks for any clarification! Steff
