Appearance
E-mail protection, claim by claim
WIN-DLP-EPIC-016 asks for adapters for Outlook and Microsoft 365 mail flow, because e-mail is still the highest-volume egress channel in most organisations.
Nothing is built. The channel exists in the contract, the capability matrix reports it unavailable with a reason on both platforms, and DLP-186 is the spike that would decide how. That is the epic's criterion met by absence.
What is worth recording is not the absence. It is what the absence looks like next to the product's own risk model.
1. Absent, and honest about it
| Claim | Proved by |
|---|---|
| The channel is reported unavailable, with the reason | platform.rs: "requires a mail gateway or client integration", on both platforms |
| Every unavailable capability explains itself | platform::tests::every_unavailable_capability_explains_itself |
| Nothing warns about a channel it cannot see | platform::tests::nothing_warns_about_a_channel_it_cannot_even_see |
| The published matrix says so | : ❌ ❌ ❌ ❌, "Needs an Outlook add-in or mail-flow integration" |
| The component is listed as not implemented | §2: outlook-connector - "Not implemented. DLP-186" |
The same caveat as print applies and is filed against it: an operator can write a policy scoped to email_attachment, publish it, and nothing says it can never fire (DLP-270).
2. The observation worth having
Channel::risk_weight in packages/contracts/src/lib.rs is the product's own statement of which channels matter. Put it beside the capability matrix:
| Channel | Risk weight | What the product can do about it |
|---|---|---|
| Mobile device (MTP/PTP) | 0.95 | Presence only. Detected is not monitored |
| Removable storage | 0.95 | Monitor only. Write blocking needs a minifilter (DLP-6, DLP-179) |
| Browser upload | 0.90 | Built and preventive where the extension is connected, on Linux and Windows; still manually loaded pending a signed published id (DLP-1203, DLP-1207) |
| Bluetooth | 0.90 | Nothing (DLP-91) |
| E-mail attachment | 0.85 | Nothing (DLP-186) - this epic |
| Optical disc | 0.85 | Detected as a device class; burn interception not implemented |
| Cloud sync folder | 0.70 | The local write is seen; the upload never is |
| 0.60 | Nothing (DLP-183) | |
| File copy | 0.60 | Seen as create-plus-read; attribution needs a minifilter |
| Clipboard | 0.50 | Built, and live only while a session agent is connected |
| Network share | 0.45 | Monitored where a share is mounted (DLP-227) |
| File open | 0.40 | Linux only, via fanotify |
| Archive creation | 0.35 | Built |
| File create / modify / rename | 0.15 | Built, both platforms, the most-tested code in the repository |
The product's coverage is close to inversely correlated with its own risk model. The channel it monitors best is the one it rates least dangerous. Of the six channels it rates at 0.85 or above, one is built and undeployed, one is monitor-only, and four do nothing at all.
That is not a defect and nobody did anything wrong: file monitoring is the foundation everything else needs, and the high-risk channels are hard for reasons this repository documents carefully - a minifilter for removable writes, a COM interface for phones, an OBEX listener for Bluetooth, an Outlook add-in or a mail gateway for e-mail.
It is worth stating plainly anyway, because two things follow from it:
- A fleet running this product today is well covered against the movements it rated 0.15, and uncovered against most of what it rated above 0.85. A customer conversation should start there rather than arrive at it.
- This epic is
release R4and prioritylow, for the channel the same codebase calls the highest-volume egress channel in most organisations. Those two judgements are in the same repository and they disagree.
3. What building it would take
Recorded so DLP-186 starts from the question.
| Approach | What it gets | What it costs |
|---|---|---|
| Outlook add-in (COM or web) | The endpoint sees the message before it is sent, so prevention is possible, and it sees the attachment as a file | One client, one platform, one vendor. Deployment through Group Policy or Microsoft 365 admin. Says nothing about mail sent from a phone or from webmail |
| Microsoft 365 mail flow (transport rule or Graph) | Every message, wherever it was sent from, including phones and webmail | Not an endpoint capability at all - it is a tenant integration, it sees mail after the endpoint has released it, and prevention is the gateway's rather than the agent's |
| SMTP gateway | Vendor-neutral, sees everything that leaves | Somebody has to route mail through it, and it sees nothing internal |
The two are not alternatives; they answer different questions. The add-in can stop somebody sending; the mail-flow integration can tell you what was sent. DLP-90 and the DLP-1178 epic are the Microsoft 365 side, and they are further along than this one. DLP-1193 is app registration and the tenant binding, the first step of either M365 route, and it is built for SharePoint discovery.
4. What is not covered
- No e-mail code exists to test, so there is nothing to cross-reference beyond the absence. The epic's criterion is met: absent, documented as absent, ticketed.
- No measurement of e-mail volume at any customer, which is what would turn "highest-volume egress channel in most organisations" from a received opinion into a reason to schedule this above something else.