EMail Returned as Attachment on MailMessage

Question

When retrieving Emails from a certain sender to an IBM Domino server, the Email Body is returned as an Attachment of the MailMessage Class. The Email Body Attachment is named something like ATT00001.txt.

When I view the original Email using the IBM Notes Web Mail UI, I can see that the Email has a single attachment which is a PDF file and no other attachments.

What would cause the Email Body to be returned in this manner.

The MailMessage.HasBodyHTML and the MailMessage.HasBodyText both return False.

Thanks,
Lance

Comments

Could you please download the mail using the Imap.GetMessage (this is important - don't download into MailMessage/MimeMessage and then save) method and then pack the email into a zip archive and send it back to us for analysis? This way we will see how the original email looks like on the server and help you resolve this issue.

Thanks,
Tomas

---

Any news on this? Was this issue resolved by applying the new version of Rebex Secure Mail as suggested in my below answer?

Answer 1

Thank you for sending us the problematic EML file.

I tested loading the original email into the MailMessage class and actually I was unable to reproduce the problem that you described.

With the code below:

MailMessage mail = new MailMessage ();
mail.Load ("email.eml");

Console.WriteLine (mail.HasBodyText);
Console.WriteLine (mail.Attachments.Count);
    Console.WriteLine (mail.BodyText);

mail.Save("email-resaved.eml");

the email parses just correctly. The HasBodyText property is set to 'true' and the Attachments.Count is "1" as it should be (only the pdf was parsed as attachment). I do not see the ATT00001.txt attachment popping is as you described.

Could you please try to download the email with the latest version of Rebex Secure Mail (e.g. 2015R4.1)? If you still experience the issue with the newest version, please send us a code repro so that we are able to reproduce this issue.

Comments

Sorry to bring back an old topic, but I have the same problem with mails from iOS Mail.

If you send a photo by mail using an iCloud account, without adding a text (just the normal "sent with my iPhone" footer), it is received as a mail with an empty body, and two attachments (ATT0002.txt and the image).

I have inspected the eml, and it is a multipart/mixed with two text/plain parts (one empty, one with the footer, both without content disposition) and the attachment (with content disposition set to inline). I know this is probably not the way it's meant to be, but using MailKit for example, I can parse the mail just fine (it returns two body parts and one attachment).

The same happened to me yesterday with an HTML mail, which came in empty with a ATT00001.html and a pdf attachment. That's why I remembered the problems I had with iCloud/iOS mail and tested it again.

Is there any way to fix this (or maybe even a setting, though I haven't found any?), other than looking for ATT...txt/html attachments and parsing them manually? Thanks!

---

This looks like our parser does not like something about the MIME structure. Can you please send one such sample email? We'll look into it.

---

Thanks, I received the sample email. At first glance, it seems this was supposed to be a signed message, but the signature part is empty. I guess that might be the cause. We will look into it!

---

No, there was no signing involved. What makes you think so?

---

Oh, sorry! I was looking at source for the message I received, not at the original.eml inside the ZIP file. Also, the signature on the outer message is perfectly fine, sorry for the confusion.

---

OK, so this is what's going on - the top-level MIME entity is "multipart/mixed", which (according to the specification) is "intended for use when the body parts are independent and intended to be displayed serially". This means that the two "text/plain" body parts are not actually two alternative views (they would have to be inside "multipart/alternative" for that), but rather two independent bodies.

The problem is that this does not actually fit into the MailMessage API. Still, we had to put the part somewhere, and we thought that the least bad option would be to put it into the Attachments collection. Technically, that's incorrect, but if we instead put it into AlternateViews, that would be incorrect as well (because the two bodies are not actually alternative body parts, as explained above).

But if all the possible options are wrong, we can at least make it possible for the user to specify which kind of behavior to use. This would be similar to the already-existing MailMessage.Settings.TreatMixedInlineAsAttachment option.

Now, we can add an option that would work like this: If there is a sub-entity inside multipart/mixed that is text/something, does not have a file name, and does not have content disposition of "inline" or "attachment", we will add it to AlternateViews collection instead of Attachments.

Does this sound suitable?

---

Yes, that sounds fine to me! Thanks!