Reply with attachmentPermissions & security
Reply with attachment runs on Microsoft Graph, which works with explicit, user-consented permissions. Here's exactly what we ask for, why — and what we never do with your data.
Three permissions, no more
When you first use the add-in it signs you in with your existing Microsoft 365 account (single sign-on) and requests these three delegated Microsoft Graph permissions — the complete set the add-in is registered for in Microsoft Entra ID (Azure AD).
| Permission | What it lets the add-in do | Why it needs it |
|---|---|---|
Mail.ReadWrite |
Read and write mail in your mailbox as you | Create the reply/forward draft that carries the original attachments, then hand it back to you to review and send. The add-in itself never sends it. |
User.Read |
Sign in and read your basic profile | Identify the signed-in account so the correct mailbox is used. |
email |
See your email address | Confirm which mailbox address you are signed in with. |
Mail.ReadWrite is the narrowest scope that can create a draft — so the boundary that matters is what the add-in actually does with it, not the scope name alone.
What it actually does with your mail
When you click Reply / Reply All / Forward, the add-in asks Microsoft Graph to create a draft of that message and to keep its attachments. It sends Graph only the recipients and your reply text; Microsoft assembles the draft — including the attachments — inside your own Microsoft 365 environment. The draft opens in Outlook for you to review and send.
What it does not do
Never stored on our servers
Your emails and attachments are never stored on our servers. The reply/forward draft is created directly between your Outlook and Microsoft Graph; attachment contents never pass through Binary Please infrastructure.
No tracking or analytics
The add-in loads no analytics, advertising, or third-party tracking code, and no marketing CDN. The only external script it loads is Microsoft's own required Office.js runtime, from Microsoft's servers — the platform mandates this for every Office add-in.
Our account server never sees your mail
Sign-in and your Pro plan are handled by a small account service that stores only your account details — name, the email addresses on your plan, billing status. No message bodies, no attachments.
On our side — how your data is handled
Processing location
The reply/forward is assembled by Microsoft Graph within your Microsoft 365 tenant, driven by code that runs in the add-in's sandbox in Outlook on your device. Binary Please operates only the account/billing service described above.
Transport
All Microsoft Graph and account-service traffic runs over HTTPS/TLS.
Data controller
Binary Please UG (haftungsbeschränkt) — support@binaryplease.com. This page is product help for how permissions work; for the binding statement, read the full privacy policy →
For admins — deploy via Integrated apps
You can deploy Reply with attachment to your users from the Microsoft 365 admin center under Integrated apps. Deploying it there lets you grant the required permissions once, on behalf of your organization, so your users don't each see an individual consent prompt.
Microsoft's how-toCan't install it yourself? Loop in your admin
In many organizations, Microsoft 365 apps and their permissions can only be approved centrally. If the install is blocked or asks for admin approval, you don't need to do anything risky — forward this page to whoever manages Microsoft 365 for your organization and ask them to deploy Reply with attachment via Integrated apps. Once they approve it, it will appear in your Outlook with no further prompts.
Permissions & security questions
What Microsoft Graph permissions does Reply with attachment need?
It requests exactly three delegated Microsoft Graph permissions — Mail.ReadWrite, User.Read and email — the complete set it is registered for in Microsoft Entra ID (Azure AD). These are delegated scopes: the add-in acts only as you, only after you or your admin consent, and only while you are signed in.
Does Reply with attachment read my whole mailbox?
Mail.ReadWrite is a mailbox-wide scope — Microsoft doesn't offer a “single message only” mail scope, and it's the narrowest one that can create a draft. What matters is what the add-in does with it: when you hit reply or forward, it asks Microsoft Graph to create a draft of that message and keep its attachments. It never sends anything on its own, and no email or attachment is ever copied to our servers.
Is my email or attachment data stored on your servers?
No. The reply/forward draft is created directly between your Outlook and Microsoft Graph, inside your own Microsoft 365 environment; attachment contents never pass through Binary Please infrastructure. Our account service stores only your account details (name, the email addresses on your plan, billing status) — no message bodies, no attachments.
Can our IT admin approve this for the whole company?
Yes. Admins can deploy Reply with attachment from the Microsoft 365 admin center under Integrated apps and grant the required permissions once, on behalf of the organization, so users don't each see an individual consent prompt.
Does the add-in use any tracking or analytics scripts?
No. It loads no analytics, advertising or third-party tracking code. The only external script it loads is Microsoft's own required Office.js runtime, which the Office platform mandates for every add-in.
Why does the new version need permissions the old one didn't?
An earlier version ran on Exchange Web Services (EWS), which Microsoft is retiring. The current version is built on Microsoft Graph — Microsoft's current, supported API — which works with explicit, user-consented permissions, so you can see exactly what you're granting.
Two buttons. Your mail stays yours.
Three delegated permissions, nothing stored on our servers. Start on the free plan today.