Note, as this is a new page you're contributing to the docs, you'll need to add a new entry into mkdocs.yml:

I'm not sure if this really belongs to "Best Practices" personally, but this doc can be relocated at a later point if no maintainers want to suggest a more appropriate location.

@reneploetz perhaps should provide some feedback on if the documentation is sufficient?

These docs seem to be missing some insights discussed in #2031 , it would be better to point out known mail client issues (with an admonition) in our docs, rather than glossing over it with only "some mail clients".

I'm not sure if this really belongs to "Best Practices" personally, but this doc can be relocated at a later point if no maintainers want to suggest a more appropriate location.

I personally would Put it in the examples section. Not Sure wether use cases or examples fits netter though.

I will leave this to my own fork.

I will leave this to my own fork.

You're not going to complete the PR because of a disagreement with the review feedback?

It seemed like a nice contribution, I understand if it's been a hassle for you. I know I've made it more work to revise before accepting, but I have tried to make that easier for you with my own time.

Thank you for the contribution! 😄

As @hnws is not going to finish this, I think I can take over and get it merged.

I will leave this to my own fork.

You're not going to complete the PR because of a disagreement with the review feedback?

It seemed like a nice contribution, I understand if it's been a hassle for you. I know I've made it more work to revise before accepting, but I have tried to make that easier for you with my own time.

Thank you for the contribution!

As @hnws is not going to finish this, I think I can take over and get it merged.

Yes, disagreement creates different forks. And you need to learn more about sysadmin.

Yes, disagreement creates different forks.

You're contributing upstream which is welcomed, but it is fair for the reviewers to ask questions and want answers before merging a PR.

You can create a fork and maintain that if you believe it's worth the trade-off for a documentation or config difference (even when there is no need to do that for what you're doing). It does not bother anyone here.

And you need to learn more about sysadmin.

I don't follow? This seems to be a misunderstanding.

You've opted out of finishing the PR because I requested the document have a less vague title than "Folders", and to provide some context early on in the document. I cited various sources where mailboxes is valid for the topic and used by some mail clients, while acknowledging that IMAP/special folders is also used elsewhere as an alternative jargon, mostly from a frontend/client interface.

I did not demand you to replace "folder" throughout the document 😕

Last word on this issue, from my perspective, from my own experience and understanding, I believe calling IMAP folders "folder" is something without any doubt and discussion.

I do not have more time arguing with you here. I might have other changes to this project.
And as a critical infrastructure to my personal life, after the discussion here, I believe it's a better idea to keep my own fork.

Mailbox usually refers to the whole IMAP structure. And folder refers to individual folders..

I thought the same way. Mail(account/box) is the whole thing. And in that mailbox there are several folders.

Today I learned, after looking into @polarathene answer, that some vendors call the "folders" mailboxes, which I personally find very confusing and never have heard of before.
On the other hand, most MUAs seem to use the folder term.

For me, the terms folder, IMAP folder or Mailbox folder are all ok. I think, the majority will know what is meant.

@hnws I can understand, that sometimes, such discussions can be exhausting - I had a few of these myself 😉 But don't get angry because of that. It's not meant bad in anyway.

I did not demand you to replace "folder" throughout the document

I think this PR is then almost ready to merge. Can we find a compromise in using one of the three (or last two) term suggestions above?

@hnws I would really appreciate, if you reconsider your fork decision and instead contributing to this project directly (this PR and future things).

@casperklein
Thanks for the kind reply here.

For this PR and in general:
My main frustration here is that as I do not want to explain something which is, again from my own experience, is a truth.
I learnt this from my work experience as sysadmin for a few years. And I thought I should find common ground here.

To be honest, maybe it's a bit offensive, but do not this this offensive, I really really put this here at good faith, as email is really a critical path of a person's daily life: If a person does not have better than average knowledge of details of how a email system works, but simply docker-compose up -d, this person should not setup self-hosted email system.
This is a lesson I learnt the hard way myself.

Mailbox usually refers to the whole IMAP structure. And folder refers to individual folders..

Today I learned, after looking into @polarathene answer, that some vendors call the "folders" mailboxes, which I personally find very confusing and never have heard of before.

The correct term is mailbox as per all IMAP-related RFCs and the server configuration language of dovecot [1]. The RFCs give "remote folders" as alternative name, but from a specification level mailbox is the correct term.

It's also correct that many MDAs use "folder" as name because - I suspect - the name is less confusing for end-users and they generally do not care about using somewhat less well-defined names. Users usually understand what a folder is and less so that they can have multiple "mailboxes" at their (mail) address.

From a mail server adminstration perspective we can decide if we want to go for the dovecot configuration language of using "mailboxes" or use some alternative variant that might be better understandable for end users. Technically, I would prefer using the dovecot configuration language (or at least some reference to it), but i think the whole discussion is really only about semantics and the question what kind of domain/technical knowledge of IMAP/dovecot we expect users to have.

Note that throughout our own documentation we are mostly using "mailbox" whenever we talk about IMAP with the documentation related to MOVE_SPAM_TO_JUNK and docs/content/config/advanced/mail-sieve.md being the sole exceptions I could find.

[1] https://doc.dovecot.org/configuration_manual/namespace/#mailbox-settings

What i initially meant by my question: #2045 (comment) was if "sharing" is the correct verb.
I read it multiple times and always understood it that multiple clients (using multiple, different account) can share the same IMAP-folder (or however you will call it - imho folder is public spread the most).

But after reading through the discussion and reading it multiple times again i think i now know what @hnws meant: Instead of that every mail client of the same acocount uses its own (local) archive IMAP-folder you can create one which is then kind of "shared" between all clients so comparable to "sent" or "inbox".

The fact that it took me a few readings and days and that "sharing" IMAP folders among all clients connected/logged-in with the same account is basically the definition of IMAP folders still brings me to the point that "sharing" might be completely missleading or am i the only one thinking in that direction?

Maybe a simple "using the same folder (on the server)" is the better choice.

All in all I can only say that i agree 100% with the answer of @casperklein. It would be very disappointing to loose you with your knowledge as a contributor. I am also 100% sure that @polarathene didnt intended to offend you in any way, just adding his 2 cents by throwing in his thoughts with the goal to improve the docs.

I would really be happy to see you finishing this PR 🚀

@wernerfred

Instead of that every mail client of the same acocount uses its own (local) archive IMAP-folder you can create one which is then kind of "shared" between all clients so comparable to "sent" or "inbox".

My understanding is that these are intended as remote IMAP folders / mailboxes on the MDA (Dovecot for us), and that any MUA (mail client) should be aware of these. Compatibility with some features of IMAP extensions may vary, which the documentation page tries to make the reader aware of.

brings me to the point that "sharing" might be completely missleading or am i the only one thinking in that direction?

Yes, I took some time to rephrase the document myself. I think it's good enough for merging and keeps both "mailboxes" and "folders" wording, making it clear early on that they're the same and these are IMAP folders.

The standard / common mailboxes are considered special IMAP folders on some clients due to the SPECIAL-USE attribute or functionality that differs them from regular folders a user may user for organizing their mail.

I did not touch on it, but there is also virtual folders which are like aliases AFAIK, eg for things like labels functionality, an example is for marking something as important (starred/favourite in some MUA).

Maybe a simple "using the same folder (on the server)" is the better choice.

According to the information provided regarding various clients, some may behave differently and only use a folder locally (at least for archiving functionality).

I am also 100% sure that @polarathene didnt intended to offend you in any way, just adding his 2 cents by throwing in his thoughts with the goal to improve the docs.

I absolutely had no intention to offend. I don't have the experience that @hnws has as a sysadmin, but tried to express that our docs should try avoid being vague on terms that vary based on context.

I tried to highlight that with the Dovecot docs choice of "mailboxes", which the RFC uses and Apple mail clients UI too. I've always personally thought of them as mail folders myself and from a user perspective I can understand the bias/preference to that usage.

However we reference it in relation to Dovecot and these are intended as technical docs for setting up an email service, I don't see any major reason to debate what is used, other than clearly defining they're the same thing early on. That's now taken care of.

@hnws

I'm sorry if I come off as difficult, I don't mean to! 😅 I am just providing feedback during review, I welcome to be corrected if you disagree, but I would appreciate adequate justification to back it up, or waiting on other maintainers to throw in their opinion.

Again, I was not trying to imply you were wrong about anything, but try to come to a common understanding based on the information available.

And as a critical infrastructure to my personal life, after the discussion here, I believe it's a better idea to keep my own fork.

I wouldn't want to make you feel that you have to fork due to our interaction here.

I'm not representative of the other maintainers, I just care about the quality of the docs and tried to collaborate with you on your contribution. I hope you can understand and appreciate that, but if it would make you comfortable to contribute in future, I can avoid being a reviewer on any future PRs of yours?

Documentation preview for this PR is ready! 🎉

Built with commit: b3c79ee

@all-contributors add @hnws for docs

@wernerfred

I've put up a pull request to add @hnws! 🎉