Possible problem with parsing Mime Part Boundary

[jhumphries83]

I recently had a misbehaving mail client provide mail headers in the following format:

MIME-Version: 1.0
From: [email protected]
To: [email protected]
Date: 18 Jan 2017 16:40:27 +0000
Content-Type: multipart/mixed;
 boundary=--boundary_0_8ab0e518-760f-4a94-acc0-66f7cdea5c9f
 
Subject: A Test Email

Note the extra carriage return and space after the Content-Type header.

When using the MimeMessage.Load method MimeKit determined the Boundary to be "--boundary_0_8ab0e518-760f-4a94-acc0-66f7cdea5c9f " (it has included the space character from the line below the Content-Type header). This results in MimeKit not detecting any of the Mime parts in the message (which in turn means I cannot process it correctly).

However when I relay the message, other mail clients do detect the mime parts and display the message as intended. Which I assume means that they are ignoring the extra line and space after the Content-Type header.

I'm not sure if this means that the extra space character should be included as part of the boundary specifier or not. Unfortunately I couldn't find any information in the relevant RFC's (822, 2045) about how headers should be parsed in this scenario.

If I remove the extra line with the space before calling MessagePart.Load MimeKit detects the other MimeParts and I can process the message properly.

What are your thoughts? Do you think MimeKit should be adding the extra space to the end of the boundary specifier or ignoring the extra line and space?

[jstedfast]

Technically, that mail client is broken... but it is trivial to work around, so now the code works around that issue.

[jhumphries83]

Great, that was quick! Many thanks! Do you know when a new release will next be available on nuget?

[jstedfast]

I was going to try and do another release around the end of the month

[jhumphries83]

Perfect, Thanks again.