Hello,
I am considering the Aspose.Email solution, but found out an issue when trying to convert some emails.
Those emails include images which should be displayed in the HTML body. After some researchs using OutlookSpy, it turns out that the ContentLocation parameter (PR_ATTACH_CONTENT_LOCATION_W) is not set in the final converted MSG, which results in images as attachments.
The code used to convert the EML is:
Aspose.Email.MailMessage msg = Aspose.Email.MailMessage.Load(emlMemoryStream);
folderInfo.AddMessage(MapiMessage.FromMailMessage(msg));
Please find attached a zip including: the original EML file and a PST file containing both a “wrong-formated” Aspose solution converted MSG file and a “correct” Outlook internal converter imported MSG file (unfortunately if including two MSG files in the zip, the attachments mapi properties disappear in OutlookSpy for some reason):
ContentLocation email sample.zip (848,3 Ko)
Best regards.
Hello @anthonypr,
Welcome to the Aspose.Email support forum!
We have opened the following investigation ticket in our internal issue tracking system:
Issue ID(s): EMAILNET-41229
Thank you.
Thank you for your answer.
Do you have any schedule for fixing this issue? Weeks, months?
This problem is currently a no-go for implementing the solution to our product.
Best regards.
Hello @anthonypr ,
The issue is being investigated. We’ll inform you on the exact terms of the fix delivery a bit later.
Thanks for waiting.
The issue of the ContentLocation parameter not being set when converting EML to MSG using third-party solutions has been reported and acknowledged by the developers of Aspose.Email. They have opened an investigation ticket with the issue ID EMAILNET-41229 to track the issue and work on a fix.
In the meantime, there are a couple of workarounds that you can try to avoid the issue:
Use Outlook to convert the EML files to MSG: Outlook can correctly set the ContentLocation parameter when converting EML files to MSG. You can manually convert the files using Outlook or use a script to automate the process.
Embed the images directly in the HTML body: Instead of relying on the ContentLocation parameter, you can embed the images directly in the HTML body of the email. This will ensure that the images are displayed correctly in the email client, regardless of whether the ContentLocation parameter is set.
Once a fix for the issue is released, you can try EML to MSG Converter for Mac to the latest version to resolve the problem.
Thank you for confirming the issue.
Always using Aspose.Email, the only reasonable solution we had so far was parsing all the EML mimeparts looking for a ContentLocation parameter, then modifying the Aspose converted MSG, setting every required ContentLocation by hand, but the conversion slowdown is simply not acceptable…
From what I understand reading other threads, updates approximately occur once a month by the end of a month. Should we now wait until the end of December for a regular .NET API fix?
Best regards.
Hello @anthonypr,
The issue has been fixed in version 23.11, which has already been published. Please check it and share feedback.
After test it’s perfect, thank you for your quickness!
Best regards.
You’re welcome.
Feel free to contact us if you have any inquiries.