Sometimes when clicking on an unread menu, the message body is missing. All normal fields seem to be present (like sender, subject), just the message text itself is empty. Clicking on another message and then clicking on the broken message again doesn't fix it. Viewing the message source also shows that most fields are present, just not the message text. What helps is discarding the folder cache, and waiting until it's done reindexing.
Further observation: the mail without body has the sender (and other metadata) of the previous mail (at least in this case: the mail in the mailing list thread that was replied to).
It would appear that the body did not get cached. Start Claws in debug mode, `claws-mail --debug`, and attach the relevant output.
I've also seen this (starting with claws 3.10 (IIRC), now using 3.11.1). It happens here with an IMAP account at an xchange-server. However the missing bodies can be fetched completely after the incomplete, cached imap mail file (located in claws' imap-chace directory) has been deleted manually. The problem seems to be the server sometimes reporting zero body length when the message is cached the first time. A possible workaround would be to let claws re-fetch cached messages when their body length is 0. For further analysis, see the attached commented_claws-mail_debug-output.txt. It contains apparently relevant parts of the (huge) full debug log generated with claws-mail --debug. There a message (ID 75684) has been fetched/cached initially resulting in an incomplete body (see line 65). Every log line where this ID is present has been left in the log file with some context. Later the cached message was deleted (rm) and then re-fetched, now with the complete body. Interestingly the first fetch is initiated by UID FETCH 75684 BODY.PEEK[HEADER] but later claws "thinks" the cached mail was already complete.
Created attachment 1466 [details] commented_claws-mail_debug-output
(In reply to comment #3) > The problem seems to be the server sometimes reporting zero body length > when the message is cached the first time. now i think im'm wrong here, see further text of comment #3
*** Bug 3618 has been marked as a duplicate of this bug. ***
This bug might be a duplicate of Bug 2257