An IMAP profile was first created for an account at danwin1210.me. The IMAP server is simply "danwin1210.me" in this case (contrary to most services which use something like "imap.server.tld"). This profile was named "Danwin - IMAP" Then for archival purposes, a POP3 profile was created for the same email account. This profile was named "Danwin - POP3" The server is also simply "danwin1210.me". Quite strangely, there is a "Default Inbox" field on the "Receive" page of the POP3 account preferences, and it's pre-populated with: "#imap/danwin - IMAP/INBOX". It's bizarre that the new POP3 profile would be aware of the IMAP account without any action on my part to associate them. This "Default Inbox" field has zero documentation https://www.claws-mail.org/manual/claws-mail-manual.html yet the syntax is cryptic so it's unclear how this field should be set. So it was left as-is. On the main screen, the left frame shows folders for "Danwin - IMAP", but not for "Danwin - POP3". Yet the "Get Mail" pulldown menu shows both. (even after a restart) I believe a few bugs are evident in this scenario: bug 1) The "Default Inbox" field is undocumented. bug 2) The two profiles get intermingled, and the POP3 account does not appear. bug 3) If the intermingling/merging of IMAP & POP3 profiles of the same account is deliberate (by design), then the user should be notified in some way, and told what to expect.
Create a mailbox for your POP account: /File/Create mailbox/MH...
Correction: /File/Add mailbox/MH...
That creates an empty mailbox, but it's not a "danwin - POP3" mailbox. So the left frame now shows: => danwin - IMAP => mail (MH) "danwin - POP3" is still missing from the frame.
One or more pop accounts can share a single MH mailbox. Because what you see is not what you expect to see, based on a pre-conceived idea, does not make this a bug.
> One or more pop accounts can share a single MH mailbox. I can see how that would be quite useful, so long as the user is in control of the decision. But at first the user doesn't seem to have control and the default behaviour is a POLA failure (https://en.wikipedia.org/wiki/Principle_of_least_astonishment). I created two C-M accounts in this order: 1. danwin - IMAP 2. danwin - POP3 So **POLA bug 1** manifested: only "danwin - IMAP" appeared in the folder frame, not "danwin - POP3". Why would a user intuitively expect acct 1 to appear but not acct 2? (I later discovered why POP & IMAP differ in this regard, but it's non-intuitive and doesn't diminish the shock of the user's first impression-- and it's still inconsistent behaviour when the top-level IMAP folder is created automatically) Then I notice that the POP3 acct has a "default inbox" field that crypticly mentions the IMAP folder (which has appears automatically associated to the IMAP acct). The documentation makes no mention of what to write in this field but the syntax is quite non-intuitive. That's **POLA bug 2**. **UI bug 1:** I later discovered that the "default inbox" field actually has a "browse" button to the right of it, which doesn't become visible unless the user widens the window enough to make it show up. The horizontal scrollbar at the bottom is insufficient for signalling to users that a browse button is cutoff if the user doesn't know there's a browse button in the 1st place. We only scroll when we know there is something to scroll to, and it looks as if the only object to run off the window is the "check mail every ... seconds" field, which many would ignore. A good fix would be to put a right arrow at the left of the field value, and have a pull-down of choices. **Documentation bug 1:** The manual should make it loud and clear that part of creating a useable POP3 acct entails manually creating an MH mailbox and pointing to it. This is not like Thunderbird where a wizard does what needs to be done. This is the only remark about it in the C-M manual: "Mail received from a POP3 account will be stored in an MH mailbox in the folder tree." It neglects to tell the user that they must create a POP3 mailbox as a separate step. Paul- I appreciate your guidance, which ultimately helped remedy my problems reported here. However, the four or so bugs I've exposed here remain bugs. The fact that your guidance was needed is in itself evidence that there are bugs here, as your guidance should not have been necessary. Now that I've overcome the C-M stumbling blocks and idiosyncracies, I don't need a fix for my sake but no doubt others will get burnt by the same POLA bugs as I have, even if they read the docs. I'm changing it from "INVALID" to "WONTFIX" b/c I have the power to and "WONTFIX" seems more appropriate. Of course, you can change it back if you insist.
Related bug: https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3431
*** This bug has been marked as a duplicate of bug 3431 ***