Thanks for your reply and the follow-up link that came afterwards. From https://dovecot.org/pipermail/dovecot/2020-August/119644.html I do get the impression that this behaviour is undesired and that it's actually a Dovecot bug to confound client and server SSL settings. I'm however not sure if the person who remarks that is actually just stating his opinion or the view of the project. However, the term "workaround" does further imply that this situation is not as intended. I would normally file a bug in a bug tracker for this (so it can at least be discussed and easily found), but it seems Dovecot doesn't have one. Is that correct?
I had hoped I had found a cleaner workaround (that could even become a default suggestion) by moving ssl_cert and ssl_key into "protocol imap {}" but it seems that even that gets evaluated when running doveadm. Is the situation literally that doveadm is parsing all configuration even if it's irrelevant for its use?
The version of Dovecot I'm running, 2.3.13, dates from well after when this error was reported in August 2020. This has me concerned that this bug is an "accepted defect", "intended behaviour" or has just been lost in discussion and due to the lack of a bug tracker. So I'm not quite sure how to continue from here. I could of course use the "!include_try" hack, but that can't be the suggested method, and if it is, it should be explicitly mentioned in the documentation and config examples in my opinion.
On 19/01/2023 11:50, EML wrote:
On 18/01/2023 22:01, Bert Van de Poel wrote:
I was quite surprised to find that doveadm requires quite broad privileges (in my case root privileges) to function properly.
This is, I think, a "feature" that was introduced in 2.3. It can make life difficult. There's a message somewhere on the mailing list describing this, but I can't currently find it. The OP wanted his users to be able to set up something, but found that they couldn't.