MIME parts returned by getAsFileAsync() don't include Content-Disposition on Outlook Win32

[DustinBrungart]

Provide required information needed to triage your issue

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: Version 2405 Build 16.0.17628.20006
• Operating System: Windows 10

Expected behavior

A bodypart should be marked Content-Disposition: inline; if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages.

Current behavior

In the Classic Outlook for Windows (Win32) JS Runtime for an event-based or spam-reporting add-in, calling getAsFileAsync() returns a multipart mime document that doesn't include content-dispositions for its attachments. This limits handling of inline attachments in downstream processing.

In Outlook on the Web and New Outlook for Windows (the web runtime), content-disposition is set as expected.

Steps to reproduce

1. Create an email with an inline image attachment.
2. Install an add-in that calls getAsFileAsync() such as the outlook-spam-reporting sample add-in
3. Run the add-in in Classic Outlook on Windows and inspect the async result (MIME document).

Link to live example(s)

To confirm my findings, I used the office-js outlook-spam-reporting sample add-in: https://github.com/OfficeDev/Office-Add-in-samples/tree/main/Samples/outlook-spam-reporting

Context

The inline content-disposition is used to analyze spam and phishing emails and present partial views of the resulting bodyparts with analysis. Grouping inline attachments and attachments separate from the main body results in inaccurate results that require additional processing to correct.

Useful logs

Inline attachment, Outlook on the web and New Outlook on Windows

Content-Type: image/png; name="sample.png"
Content-Description: sample.png
Content-Disposition: inline; filename="sample.png";
	size=56004; creation-date="Tue, 18 Jun 2024 18:04:07 GMT";
	modification-date="Tue, 18 Jun 2024 18:04:15 GMT"
Content-ID: <fe9e3b24-b637-4ce4-89f9-93dfa595c75d>
Content-Transfer-Encoding: base64

Inline attachment, Classic Outlook on Windows

Content-Type: image/png; name="sample.png"
Content-Transfer-Encoding: base64
Content-ID: <fe9e3b24-b637-4ce4-89f9-93dfa595c75d>

[exextoc]

Ultimately, the underlying cause is that OWA/New Outlook, use a different MIME converter than Classic Outlook. So there will be small differences like this. This issue has been put on our backlog, but I don't know if/when it will be fixed. You may be able to workaroudn this issue by getting the EML file via Graph or EWS.