<div dir="ltr"><div>TL;DR: 🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩<br></div><div><br></div>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).<div><br></div><div>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).</div><div></div><div><br></div><div>I think the real issue here is that Dovecot is removing <u><i>existing, long-standing, critical</i> functionality</u> from the open source version. That is a huge, huge red flag.</div><div><br></div><div>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).<br></div><div><div><br class="gmail-Apple-interchange-newline">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.</div><div><br></div></div><div>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. </div><div><br></div><div>I've also loved the PowerDNS project for a decade and a half, so this removal of <i>existing functionality</i> 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.</div><div><br></div><div>But removing long-standing features is a bad look. Please reconsider this decision.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 27, 2022 at 4:04 AM Jan Bramkamp <<a href="mailto:crest@rlwinm.de">crest@rlwinm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 27.10.22 04:24, Timo Sirainen wrote:<br>
> Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with:<br>
><br>
>   * Database (sql/ldap/whatever) containing user -> backend table.<br>
>   * Configure Dovecot proxy to use this database as passdb.<br>
>   * For HA change dovemon to update the database if backend is down to move users elsewhere<br>
>   * 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).<br>
><br>
> All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director.<br>
Thank you for putting what is about to be lost to the community edition <br>
into an operational perspectiv: no reason to panic. Nobody is taking <br>
replicated active-passive pairs from small to medium scale operators. <br>
Neither are the hooks required for more fancy load balancing and <br>
steering on the chopping block.<br>
</blockquote></div>