Edit 8/22/2024: please see our new blog post on the subject for updates on the Message Recall feature.
At Microsoft Ignite several years ago we announced that we were working on a new cloud-based m...
Updated Oct 04, 2024
Version 14.0
Blog Post
KevinShaughnessy
Microsoft
MicrosoftTGecko no it won't be coming to Exchange on-prem. The architecture utilizes various components and microservices only available in the M365, and as I'm sure you've heard before our strategic focus of our development investments is the cloud.
hatsikidee three questions:
1) Can a sender send any message from the past.
A: As noted in the above FAQ: Is there a time limit past which you can’t recall a message?
No, there is no time limit, just like the classic message recall feature. Providing tenant admins the ability to customize a time limit for their organization is under consideration for a future update.
2) Will this only work for messages sent since this feature is active? Or older messages too?
A: Older messages too.
3) You say that the success rate is over 90%. When will it not work? Only if the recipient mailbox is unavailable? Or other situations too?
A: Messages sent to external recipients won't be recalled by design. That's the most common one. A few other corner case examples (not comprehensive):
* If the recipient mailbox isn't available (and remains unavailable for 24 hours for some reason)
* If the recipient has a Hard Delete rule that acts on the message,
* An ETR drops the original message before it reaches the mailbox
* The original message gets quarantined
* The original (or Recall) message is under moderation
>>[recall externally sent messages] can be enabled with mutual trust or federation settings of some sort, would be highly useful.
A: I think that's a great idea and would seem a reasonable way to address the ownership/privacy concerns about recalling externally that we're trying to honor with this release. Thanks!
>>allow recalls if the message went through a 3rd party connector?
A: No, sorry. For the new Message Recall if it leaves the service at all we won't recall, even in a scenario like yours where it's just roundtripping out to Azure then back again. But I agree it's a scenario we should take a look at potentially supporting in the future. Thanks for the feedback.