We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

V.17.6.0 not able to recognize .msg attachment format when attached to .eml file as TNEF

Aspose.Email Product Family
#1

Apparently Aspose.Email is not able to determine the correct format of a msg attachment when embedded inside an .eml message.

Attachment format: “Eml”. ===> Expected was :“msg”.
Attachment content MIME type: “message/rfc822”. ===> Expected was :“application/octet-stream”.

I’ve tested this behaviour against an older version we used to use (5.5.0).

Counterproof: if you try to call FileFormatUtil.DetectFileFormat straight on the attachment file (“case 2a.msg” detached from the email) then Aspose detects the correct format.

You can test this behaviour using the script I’ve attached (Program.cs) and the test files, all of them are included in code_and_testfiles.zip (30.1 KB).

#2

Hi,

Thank you for writing to Aspose Support team.

When an email file is loaded using MailMessage, its attachments are also converted to EML format. This is expected behavior of the API and that is why the latest version of the API returns EML file format for the attachment. Please let us know if we can be of any additional help to you in this regard.

#3

Hi Kashif,
Thanks for your reply. Ok I understad this new behaviour of the API. Is there any other class I can use if I want to keep the .eml mail format and the .msg attachment format?

Thanks,

Giulio

#4

Hi Giulio,

We are sorry but there isn’t any other option available to retain this information while using MailMessage, and this is the only class for loading EML messages. Please let us know if you have any further query related to the API.

Thanks,

Kashif

#5

Hi Kashif,

Thanks for your reply. I understand this, can you confirm that this behaviour is against how MailMessage.Load used to be?
In one of Apsose.Email former version (5.5.0), this issue was not present. All the attachment formats were retained regardless the parent email format.

Thanks

#6

@workshare,

The behaviour seems to be result of a previous change request by our customers. However, we have requested our Product team to check the possibility of any provision where the old behaviour could also be retained. An investigation ticket with id: EMAILNET-38776 has been logged in our issue tracking system for further consideration of this by our Product team. We’ll update you here once there is some feedback available in this regard.

#7

The issues you have found earlier (filed as EMAILNET-38776) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by kashif.iqbal