Currently we are using Aspose.Email for transforming msg/eml formats to PDF/RTF/TEXT.
Microsoft changes to inline images are represented in the HTML body of Outlook emails in Outlook on the web and the new Outlook for Windows.
Previously, inline images in the HTML mail body were represented with a URL containing the attachment ID as a query parameter.
Going forward, the URL for inline images will no longer contain the attachment ID.
As a result, the current parsing logic won’t be able to correlate the inline image in the mail body with the attachment ID or Base64 value of the image.
As per below information, this change may impact inline images when using the attachment ID.
Summary
Aspose.Email works with the original MIME content of .msg and .eml files. It does not rely on the Outlook‑Web‑App (OWA) inline‑image URLs that Microsoft is changing, so the upcoming URL format change should not affect the normal Aspose.Email conversion to PDF, RTF, or plain‑text.
Why it happens
OWA currently renders inline images in the HTML body using a URL that contains an attachmentId query parameter.
Microsoft plans to remove that parameter and use a generic reference instead.
Aspose.Email parses the raw MIME of the message: it reads the Content‑Id header of each attachment and resolves inline images via the cid: scheme (or Content‑Location). The OWA‑generated URL exists only in the HTML that OWA returns to a browser; it is not part of the original message.
Consequently, as long as you load the original .msg / .eml file (or a MailMessage object) into Aspose.Email, the library will continue to locate and embed the inline images correctly.
What to do next
Continue with the standard workflow – load the message and convert it directly.
// Load the original MSG or EML file
MailMessage msg = MailMessage.Load("sample.eml");
// Convert to PDF (inline images are preserved)
using (FileStream outStream = File.Create("output.pdf"))
{
msg.Save(outStream, SaveOptions.CreateSaveOptions(SaveFormat.Pdf));
}
If you are obtaining HTML from OWA first (e.g., via Microsoft Graph) and then feeding that HTML to Aspose.Email, you may encounter the new URL format. In that case:
Replace the OWA URLs with proper cid: references before conversion, or
Prefer loading the original MIME message instead of the OWA‑generated HTML.
Verify linked resources when working with HTML (optional, useful for custom processing):
// Get the HTML body that contains CID links
string html = msg.HtmlBody;
// Enumerate inline images
foreach (LinkedResource lr in msg.LinkedResources)
{
Console.WriteLine($"CID: {lr.ContentId}, Name: {lr.Name}");
}
Perform a quick sanity check after the Microsoft change is rolled out:
Load a recent .msg / .eml file that contains inline images.
Convert it to PDF/RTF/TEXT using the code above.
Confirm that the images appear as expected. No code modifications are anticipated for the standard workflow.
Status – Based on current information, the change to OWA inline‑image URLs is not expected to break Aspose.Email conversions. If your process depends on OWA‑generated HTML URLs, apply the adjustments described in step 2; otherwise, no action is required.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.