If I open the attached msg file inside an Aspose.Email.Outlook.MapiMessage object and use this aspose-authored code to distinguish between inline and non-inline attachments then I can see there are three inline attachments. Each is a jpeg image embedded in an email signature.
But - if I open the same msg file inside an Aspose.Email.Mail.MailMessage object, this tells me that the Attachments collection contains three items but the LinkedResources collection is empty.
The three files are inline, so they should appear in the LinkedResources collection not the Attachments collection.
Hi Brian,
Thank you for contacting Aspose Support team.
We are able to observe the issue as you have stated. However, if we open your sample MSG file in MS Outlook , we are not able to find the embedded image anywhere in the message body. Could you please help us locate the images in the message body? We’ll further investigate the issue at our end for assisting you further.
Thank you very much for the prompt reply Kashif.
I didn't author the msg file - it's one I was given, so it represents a real world email, not a test case I've constructed. When I open the msg in Outlook I don't see the images in the document body either.
But both MailMessage and MapiMessage agree that the msg does contain attachments, I raised the issue because those two classes treat the attachments differently. I would like MailMessage to list the attachments in its LinkedResources collection rather than its Attachments collection. MapiMessage correctly identifies the attachments as inline.
Or to put it another way, how can I use MailMessage to identify that the attachments are inline and not distinct?
Hi Brian,
We have further investigated this issue at our end and it seems to be an expected behavior. The MapiMessage attachment contains the MapiPropertyTag.PR_ATTACH_CONTENT_ID_W tag, so it is determined as inline.
On the other hand, Aspose.Email checks whether the htmlBody contains reference to an attachment when we load the msg into MailMessage and it is not determined as inline if reference is not found in the message body. So, the exact conditions for inline attachments are as follow:
1. the IsInlineAttachment method returns true
2. htmlBody contains reference to an attachment
Hi Kashif,
I agree that as an aspose developer looking through the aspose source code you might well conclude that it is expected behaviour, just because "that's what the code does". But - shouldn't this be about end-user expectations? My expectation is that MapiMessage, MailMessage and Outlook should all treat attachments the same way.
But since MailMessage has a different behaviour to MapiMessage and Outlook I'm now faced with having to use MapiMessage just to handle attachments, but keep using MailMessage elsewhere, which is inconvenient.
Hi Brian,
This is a special case where the API has no such information in MailMessage to tell if it is an inline attachment. We know that user’s expectations should be a uniform behavior but the implementation rules govern the output and it can’t be changed for this special case only. If you find some other case where an inline image (referred from MSG body) in attachment is shown as regular attachment, please share with us. We’ll investigate the issue for assisting you further.
I've just found some surprising aspose Email object behaviour:
Open the supplied msg file in a MailMessage. Each item in its Attachments collection has Inline set to false.
Open the MapiMessage directly on the supplied msg file, and IsInlineAttachment returns true for each item in the MapiMessage Attachments collection.
But - if you first construct a MailMessage from the msg file and then use that to construct a MapiMessage, this time if you pass each member of the MapiMessage Attachments collection in turn to the IsInlineAttachment function, it returns false on each one.
So the Attachments in a MapiMessage behave differently depending on whether it was constructed directly from an msg file, or constructed from a MailMessage constructed from the same msg file.
Is this expected behaviour?