When local mailbox (located in /var/mail/) contains an empty message, claws-mail fails in retrieving messages in that local mailbox file. Only indication of failure is an error message in console (or .xsession-errors), but no indication on GUI. Error message : (claws-mail:1297): Claws-Mail-WARNING **: 12:48:54.224: malformed mbox: /home/xxx/.claws-mail/tmp/tmpmbox.0x1fa6c80: message 1 is empty Issue seems to come from the test conducted in lines 222-230 from mbox.c (if no lines in the message, then it stops). Nota : RFC 822 is allowing such message without body : "A message consists of header fields and, optionally, a body" To be RFC compliant claws should load that empty message. Alternatively better behaviours could be to drop that empty message, or add a blank line in its body to simulate a non-empty message, or add in its body some kind of information string mentioning the message is empty. This is a blocker in the sense that current behaviour is just preventing claws to fetch mails while not informing the user of the issue. Nota : when the issue appears, the only way to fix the problem is to open the mailbox file in a text editor, find the empty message (= a line starting with From, followed by only an empty line before another line starting by From), and remove it. Then claws can fetch messages without complaining (this can be painful depending of number of mails is that mailbox file !).
No such problem here. The empty message is collected without error. I see no "malformed mbox" debug message. Which suggests that that debug message is correct in your case, and that's the problem.
If you put this kind of file as /var/mail/xxx "From toto@test Sun Jun 14 18:29:48 2020 message before empty message From toto@test Sun Jun 14 18:29:49 2020 From toto@test Sun Jun 14 18:29:50 2020 message after empty message " You'll get : (claws-mail:8078): Claws-Mail-WARNING **: 18:32:08.757: malformed mbox: /home/xxx/.claws-mail/tmp/tmpmbox.0x8e2320: message 1 is empty If you remove manually the 2nd message, leaving the text file with : "From toto@test Sun Jun 14 18:29:48 2020 message before empty message From toto@test Sun Jun 14 18:29:50 2020 message after empty message " Then it works like a charm.
I tried that: non-empty msg, followed by empty msg, followed by non-empty msg. I received all 3 msgs without error.
In comment #2, you said ------------------ If you put this kind of file as /var/mail/xxx "From toto@test Sun Jun 14 18:29:48 2020 message before empty message From toto@test Sun Jun 14 18:29:49 2020 From toto@test Sun Jun 14 18:29:50 2020 message after empty message " ----------------------- That is invalid. See RFC 4155
I checked RFC 4155 and you're right I forgot the empty line between the 1st & 2nd messages. But I confirm that with the following text file I have the error. "From toto@test Sun Jun 14 18:29:48 2020 message before empty message From toto@test Sun Jun 14 18:29:49 2020 From toto@test Sun Jun 14 18:29:50 2020 message after empty message " I've experienced the issue on administrative mail address receiving cron task results and for whatever reason on a regular basis I exposed to this kind of issue (having an empty message in the middle of correct ones).
In your example you show no message at all, not even headers, you just show separators. That's the problem.
I do agree that such message is just a nonsense. But as far as I understand that's RFC compliant and unfortunately it can happen (I'll post actual example when my cron daemon raise another one) => claws should not react as it does in such occasion. Preferably it should load normally the empty message, or treat it as it does with other empty mails having at least one header = just drop the mail (which is not exactly an expected behaviour neither). For example currently this other trial is not raising error, but all 3 messages are just dropped away without any notifications nor errors in console : "From toto@test Sun Jun 14 18:29:48 2020 message before empty message From toto@test Sun Jun 14 18:29:49 2020 Received: from toto From toto@test Sun Jun 14 18:29:50 2020 message after empty message "
I agree that just ignoring it and moving on (i.e. dropping it) is perhaps better than bailing out. This would not be dropping a message, because there is no message, just a separator.
I think that removing the test conducted in lines 222-230 from mbox.c, should do the job : /* warn if email part is empty (it's the minimum check we can do */ if (lines == 0) { g_warning("malformed mbox: %s: message %d is empty", mbox, msgs); claws_fclose(tmp_fp); claws_fclose(mbox_fp); claws_unlink(tmp_file); return -1; } Would that be possible to remove these lines from the code of a coming version ?