2 bugs in attachment class

Please run my sample, it will load my winmail.dat and will show each attached file’s .Name and .IsEmbeddedMessage property
You will see 2 bugs:

  1. The .Name of Save 40% and impress every audience.msg is shown incorrectly (without .msg extension)
  2. IsEmbeddedMessage is incorrectly returning False for all types of messages I’ve attached to this TNEF.
  • I’ve created this TNEF using Outlook 2021 build 16.0.15128.20264, and not using any 3rd party SDK.

WindowsApplication1.zip (1.2 MB)


We have logged this problem in our issue tracking system as EMAILNET-40811. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.


It is to inform you that the issue which you are facing is actually not a bug in Aspose.Email. So, we have closed this issue (EMAILNET-40811) as ‘Not a Bug’.

The IsEmbeddedMessage property is true when the attachment has content type “message/rfc822”. This happens when converting from msg(TNEF) if the attachment is added as an Outlook message. Only messages in MSG format can be added as Outlook messages. In the source file, all attachments are added as a byte array.

The message named ‘Save 40% and impress every audience’ does not contain any extension. Please check the attached image. attachment detail.jpg (607.0 KB)

1 Like

1st, I didn’t create the TNEF myself, automatically created by latest Outlook version.
2nd, you mean IsEmbeddedMessage = True If Content-Type = “message/rfc822”?
So ole2 msg/oft or emlx / other message types are not considered as embedded message? Not wise IMO.
3rd, if you say it’s based on the Content-Type, assume the message does not have any extension at all, should not make a difference right?

Finally, if we forget all the above, do you have a full recursive TNEF extractor code sample? This was what I was going to write! To extract ALL the files inside the TNEF recursively, to process all the message types attached, among with all inner attachments. Possible?


Yes, your understanding is correct.

The reported issue was that the Attachment.Name and Attachment.IsEmbeddedMessage returns incorrect values. After analysis, we found that the message named ‘Save 40% and impress every audience’ does not contain any extension.

Yes, your understanding is correct.

Regarding extracting the embedded object, please read the article : Working with Attachments and Embedded Objects.

Well, can you please re-consider this logic?
As well as the other attachments which HAVE correct extensions are also returning IsEmbeddedMessage as False.

Misunderstanding! I meant how do you claim the extension based detection vs content based? Anyway…

Useless, can’t imagine to write a full depth recursive attachment extractor using the current SDK structure / limitations. :frowning:


Please share your input file that contains the embedded object with and without extension. We will investigate the issue and provide you information on it.

We have closed the ticket EMAILNET-40811 as ‘Not a bug’. The message named ‘Save 40% and impress every audience’ does not contain any extension.

With Aspose.Email, you can extract the embedded objects. Please let us know the issue that you are facing while extracting the attachments.

Since the real support engineer is not directly engaged, such misunderstandings can occur, OK let’s forget about that attachment, there are more files attached marked with RED in your snapshot:
attachment detail.jpg (643.1 KB)


Following is the detail of EMAILNET-40811 after analysis.

This issue was closed as ‘Not a bug’ because there is no extension in your input file.

The IsEmbeddedMessage property is true when the attachment has content type “message/rfc822”

We have logged separate ticket for your case as EMAILNET-40861 for further investigation. You will be informed once there is an update available on it.


Regarding EMAILNET-40861, in our opinion, an embedded message should have the same structure (format) as the main message. Otherwise, it’s an attached message.

You can use below code for recursive analysis of TNEF data. Hope this helps you.

public void Test()
    MapiMessage msg = MapiMessage.LoadFromTnef("winmail.dat");
    foreach (var mapiAttach in msg.Attachments)

private static void ProcessAttachment(MapiAttachment mapiAttach)
    if (mapiAttach.BinaryData != null && mapiAttach.BinaryData.Length > 0)
        MapiMessage message = null;
        MemoryStream ms = new MemoryStream(mapiAttach.BinaryData);
        FileFormatInfo info = FileFormatUtil.DetectFileFormat(ms);
        ms.Position = 0;
        switch (info.FileFormatType)
            case FileFormatType.Msg:
                message = MapiMessage.Load(ms, new MsgLoadOptions());
            case FileFormatType.Eml:
                message = MapiMessage.Load(ms, new EmlLoadOptions());
            case FileFormatType.Mht:
                message = MapiMessage.Load(ms, new MhtmlLoadOptions());
            case FileFormatType.Emlx:
                message = MapiMessage.Load(ms, new EmlxLoadOptions());
        if (message != null)
            foreach (MapiAttachment innerAttach in message.Attachments)
1 Like

I have added case FileFormatType.Tnef: .LoadFromTnef
And also moved mapiAttach.Save(mapiAttach.DisplayName); to the 1st line so all inner items themselves are also saved!

  • 1st, the RtfBody of items (richbody.rtf) is not extracted, how to include it?
  • 2nd, to add support for attachment extraction of Ics and Vcf items:
    case FileFormatType.Ics/Vcf:
    message = MapiMessage.Load(ms)
    with no options is correct?
    Thanks :slight_smile:


In this case, please try to load the ICS and VCF without load options using MapiMessage.Load(Stream). If you still face problem, please share ‘winmail.dat’ that contains these types of attachments. We will investigate the issue and provide you more information on it.

1 Like


  • 1st, the RtfBody of items (richbody.rtf) is not extracted, how to include it?

And the issue I’ve reported at the beginning also applies to .eml files, their names are returned without extension! Tried a few different extensions all created with Outlook 2021 and all of them had this issue.
Tried to extract them using Mailbee and the extensions were all OK.


Please share the winmail.dat file here for testing.

Please check my reply about this issue.

Sample .dat file inside the project release folder:
WindowsApplication1.zip (1015.8 KB)

  1. Where’s the MapiAttachment.IsInline property? I mean how to distinguish between a normal and an Inline attachment?

  2. And MapiAttachment.Size in bytes? .BinaryData.Length is what I’m looking for?

  3. Please give me a sample to include the InlineAttachmentExtractor to this provided sample.

  4. Please specify the difference between .DisplayName vs .FileName vs .LongFileName?
    In many cases, .DisplayName has value while the other 2 are blank!
    An issue:
    If a.eml is attached to the root of TNEF, the file name includes extension.
    But if b.eml is nested inside the a.eml, it will not return the extension anymore!

  • And also, saving it with no extension will result in corrupted file as seen in these 2 screen shots:
    Untitled.png (11.8 KB)
    Untitled2.png (21.5 KB)


We are investigating this issue and will get back to you soon.

Hi, after using MapiMessage.Load can I use RTFBody of MapiMessage to save it as richbody.rtf ?
But the result is corrupt!

If String.IsNullOrEmpty(MyMapiMessage.BodyRtf) = False Then File.WriteAllText(OutputFolder + “richbody.rtf”, MyMapiMessage.BodyRtf, Encoding.UTF8)

Hardly an excuse, did you ever tried to make some test messages using Outlook and parse the TNEF file? I’m using Aspose and Mailbee side by side, and some tools as well, comparing all results.
For example, when message format is html, attachments are added different as when the format is RTF:
1.png (14.3 KB)
2.png (15.1 KB)
So, when an obvious misbehavior (even if not called a bug) is rejected…

This sample will show it:


Please read the Aspose.Email supported file formats from here:
Supported File Formats

If you want to work with RTF file format, please use Aspose.Words for .NET.

As per our understanding, you are not satisfied with the analysis of this issue. We have logged a new ticket as EMAILNET-40885 to investigate this issue again. However, the application shared in your last post is different from first post.

Could you please share some more detail about your concerned issue? We will then update the ticket EMAILNET-40885 accordingly.