Happy Holidays, And if you like me are working throughout so more senior engineers get their holidays, my condolences hah Taking the time to bring our dovecot.conf into the 2021/22 era .since its quiet time of year, Do I read it right that where we have things like service imap { process_limit = 1024 executable = imap imap-postlogin are not needed now ? and process limit is a global option? things like pop3/imap_client_workarounds = fooy are now global options, not to be in protocol { } sections ? I am reading the example conf files and see these outside the protocol sections where they have in the past lived, this is what makes me think they are now global and not needed in sub sections. but I may be missing some linking going from file to file , we have forever updated our single config file, just fixing whatever breaks when major versions break something, easier to find options in one file, rather than trying to sift through 40 included files like I am looking at now :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20211230/7ef8d7ea/attachment-0001.htm>
On 2021-12-30 03:34, Laura Steynes wrote:> easier to find options in one file, rather > than trying to sift through 40 included files like I am looking at now > :-)you dont have spare times doveconf -n no need to read more if something should change to the better, it would be better default config, that could lead to less questions on why and how to get xxx to work, currect is not that much helpfull for setup new things with unless we all are developpers sadly, and now that dovecot is not enterprise anymore there is less support there aswell :(
On 12/30/21 10:34, Laura Steynes wrote:> Do I read it right that where we have things like > service imap { > ? ? ? ? process_limit = 1024 > ? ? ? ? executable = imap imap-postlogin > ? > are not needed now ? > and process limit is a global option? > > things like? pop3/imap_client_workarounds = fooy > are now global options, not to be in protocol { }? sections ? >All options are in a sense global. imap_client_workarounds would only affect imap anyway, so the question of putting it the protocol imap {} section or outside is inconsequential. You would want to put an option in a section when it _would_ affect everything, but you don't want it to. You can also group all imap-only options in a protocol imap {} section if that seems neater to you, and doesn't break anything. You can override a global option in a service XXX {} or protocol XXX {} section, and the global may be explicitly specified, or the default.