jstedfast/MimeKit

TNEF File Truncated

schmitch opened this issue · 5 comments

schmitch commented

Describe the bug
Hello we have some customers who have generated a winmail.dat file. we than use the Mimekit converter to move it to a MimeMessage and than we save the MimeMessage, unfortunatly the file looks "truncated" because the MimeMessage is a multipart/* file, however the ending multipart header is missing. The file also has a multipart header like Content-Type: multipart/mixed; boundary="=-46X+X7Hv5KQfEJJdIqw4+A==".

What is also strange is that the winmail.dat contains pdf's and the pdfs looking broken, however only the last one, if it only contains one it is broken, if it contains two the latter one is broken.
Sadly I can't share our Testfile yet and I'm trying to generate one.

However the biggest problem is that the file does not end with the Mime Boundary like --=-46X+X7Hv5KQfEJJdIqw4+A==-- it's missing. Thats why I think that content is missing.

Platform (please complete the following information):

  • OS: MacOS
  • .NET Runtime: CoreCLR
  • .NET Framework: .Net Core 7
  • MimeKit Version: tested 3.1.0 and 4.1.0

Expected behavior
A clear and concise description of what you expected to happen.

should always have a mime boundary ending like --=-46X+X7Hv5KQfEJJdIqw4+A==--

schmitch commented

found the issue, it's the newline format:

    var formatOptions = FormatOptions.Default.Clone();
    formatOptions.NewLineFormat = NewLineFormat.Dos;
jstedfast commented

Not ending with an end-boundary seems odd and setting FormatOptions.NewLineFormat doesn't seem like it should fix that issue.

That said, I am not surprised that that would fix the PDF issue because the PDF format typically requires DOS line endings to decode correctly.

I might need to modify the TnefPart logic to enforce base64 encoding for PDF data which should also fix that part of the issue.

schmitch commented

btw. I also do not think that the dos line ending fixed it. I already had base64 output, so I'm still a little bit clueless. It did not work for a while, I changed my reproducer and it started working for all files.... so maybe I was stupid and did something wrong. maybe my os did not correctly flush the file.

I doubt that this is a bug

  • 👍1
schmitch commented

I just rechecked and I could not really reproduce it why it felt truncated, maybe my input file got broken while I downloaded the test files, I will close it until I stumble upon it again with more input.

I retried without the dos output and still everything works, so maybe it was a broken input file

jstedfast commented

A missed Stream.Flush() could definitely have cause the issue (or a truncated download).

Glad you got it working.