MBox file processing failure when extra data is present

GemBox.Email
1

Hello,

We have come across an error processing the MBox files that have some extra pieces of information within them after the boundaries

I have simplified the message as much as possible to contain only the issue-generating piece:

From 1811091568326176055@xxx Tue Sep 24 15:25:13 +0000 2024 
Content-Type: multipart/alternative; boundary=“111”
–111
Some content
–111–

Additional metadata (with \n before and after)

From 1811091568326176055@xxx … (next message)”

These kinds of messages lead to “Unexpected end of stream”. In one of the older versions, we could also see the mbox successfully processed, but it returned only the messages that did not have this metadata.

I know that most of the tools generate the mbox file with all the metadata being stored within headers; there are still some tools that generate it with these extra bits.

My expectation working with other mbox processing tools would be to just have this metadata included as plain text and not throw an error when failing the processing.

The code we use for processing is quite straightforward single line that throws an exception:

var messages = MailMessageCollection.Load(sourcePath);

Thanks for your help!

2

Hi Oleksandr,

Can you please send us your Mbox file so we can reproduce this issue?
You can send it to us via email or support ticket, see the Contact page.

Regards,
Mario

3

Hey Mario,

I have just retested the latest version, and now it is back to its previous behavior, where it doesn’t fail but ignores the following messages in case it sees \n\n (from what I can see).

In the following case, it will recognise only the first email

Here is the entire content of the mbox file. Do you want me to send it as a file as well, or is this fine?

From 111@xxx Wed Sep 25 17:25:36 +0000 2024
To: random@gmail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="555"
--555
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
SomeText

--555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Some more text

--555--


Metadata,
Metadata,

From 111@xxx Wed Sep 25 17:25:36 +0000 2024
To: random@gmail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="555"
--555
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
SomeText

--555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Some more text

--555--
4

Adding just one extra newline breaks the file and returns “Unexpected end of stream”

From 111@xxx Wed Sep 25 17:25:36 +0000 2024
To: random@gmail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="555"

--555
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
SomeText

--555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Some more text

--555--


Metadata,
Metadata,

From 111@xxx Wed Sep 25 17:25:36 +0000 2024
To: random@gmail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="555"
--555
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
SomeText

--555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Some more text

--555--
5

Hi Oleksandr,

Please try again with this latest package:

Install-Package GemBox.Email -Version 2025.10.102

Does this solve your issue?

Regards,
Mario

6

Hello Mario, amazing, it does not break and returns the correct number of messages.

Just wanted to clarify one thing. In case we have the Mime Object with boundaries, like in the example I have posted, the metadata is simply ignored, whereas in the case of only a text body with no boundaries, we have the metadata included in the result message body.

Is it expected behavior?

7

Yes, that is expected behavior.

8

Great, thanks very much for such a quick response and fix as always!