Support for Native IPC/Named Pipes in Outlook On-Send Add-ins

[pza-dev-brcm]

Context
We are developing an Outlook On-Send Add-in designed for enterprise policy enforcement. When a user clicks the Send button, our add-in intercepts the event to perform the following:

• Data Extraction: Gather metadata including Subject, Recipient List, and Body content.
• Attachment Analysis: Inspect attached files for compliance.
• Policy Processing: Run the gathered data against a local policy engine.
• Action: Decide whether to allow the email to be sent, block it, or prompt the user for justification.

Current Implementation & Pain Points
To facilitate this logic, we currently utilize a local web server that the add-in communicates with via HTTP/HTTPS requests. This architecture introduces significant friction:

• Deployment Complexity: Distributing and maintaining a local web server across a fleet of enterprise machines is heavy.

• Security & Certificate Overhead: On macOS, the requirement for HTTPS necessitates the generation and management of local SSL certificates. This is a significant barrier for both development and stable production deployment.

• Reliability: Relying on the network stack (even on localhost) for a critical "On-Send" blocking action introduces potential failure points (port conflicts, firewall interference) that can prevent users from sending mail.

The Request
Can Microsoft provide an alternative, native communication mechanism—such as Named Pipes or a Native Messaging Broker—that avoids the need for a local web server?

We believe a "Broker Process" model (similar to how modern Browser Extensions communicate with local host applications) would be a much more robust and secure solution for Office Add-ins. This would remove the dependency on the networking stack and SSL management, particularly on macOS.

Expected Behavior
A mechanism where the JavaScript manifest can define a native application/pipe to communicate with, allowing the On-Send logic to pass data to a local process and receive a "Allow/Deny" response without triggering web-server-related overhead or security prompts.

Evidence of Current Infrastructure Fragility (CORS/PNA Issues)
We have recently observed that our OWA (Outlook Web App) Add-in has stopped functioning in Google Chrome due to updated Private Network Access (PNA) policies.

Error observed: > Access to [Local Web Server Address] from origin https://outlook.office.com has been blocked by CORS policy: Permission denied for this request to access unknown address space.

This highlights the "moving target" nature of using a local web server. As browsers continue to tighten security between public origins and localhost, the local web server architecture for Add-ins becomes increasingly fragile and prone to breaking changes outside of our control. A Native IPC/Named Pipe solution would bypass the browser's network security stack entirely, providing a stable, enterprise-grade communication channel.

[ElizabethSamuel-MSFT]

@pza-dev-brcm Thanks for sharing this approach.

@exextoc Can you take a look?

Thanks.

[pza-dev-brcm]

Comment Update: Observed Parity in Microsoft Edge and Resulting Security Risks

We would like to add a critical update regarding the evidence of infrastructure fragility. We have confirmed that Microsoft Edge is now exhibiting the same behavior as Google Chrome, further complicating the deployment of our OWA Add-in.

Specifically, recent browser security enhancements in Edge now prompt users to manually "allow" or "block" the communication channel between the Add-in and the local DLP agent. While our Add-in strictly conforms to Microsoft standards, these browser-level shifts interfere with the intended communication model.

This creates a significant Data Loss Prevention (DLP) risk: if a user inadvertently or intentionally blocks this communication, the DLP agent loses the ability to monitor OWA usage, creating a critical security blind spot. Currently, our only recourse is to recommend that customers implement complex GPO policies (Windows) or MDM profiles (macOS) to force-allow this communication.

This reliance on external browser configuration further underscores our request for a native communication mechanism (such as Named Pipes or a Native Messaging Broker). A native solution would bypass these browser-driven network prompts entirely, ensuring a stable, enterprise-grade security posture that does not depend on end-user interaction or fragile browser-specific workarounds.

[sidsprasad]

@pza-dev-brcm Thanks for opening this issue. I was looking for a solution for the same thing for my company, and came across this. My application needs this not only for On-Send events, but for more general IPC.

@ElizabethSamuel-MSFT @exextoc Is this something you would be able to prioritize please?