Cloud-based Message Recall in Exchange Online

My apologies for not responding sooner to these questions/comments. My subscription to get notifications apparently expired some time ago.

waterdoe >>Please DO NOT inform the recipient, not least re instant recalls (e..g, within 30 minutes), otherwise it will defeat the purpose. 

Any update in the future that we might do to inform a recipient the message was recalled we’d make disabled by default and give tenant admins complete control whether or not to enable it. We’re considering two options an admin can enable: 1) notify recipients when a message that they read was recalled; 2) notify all recipients when a message was recalled. But again, if we provide this capability admins will have the choice to enable them or not.

PearlDiver >>I was able to recall a mail, my colleague first saw it in his inbox and then after I recalled, it disappeared. However, the Recall Report indicates that this was unsuccessful. (Translation: Messages sent to external or on-premise recipients cannot be recalled). Any idea why this is happening..? 

We tag any recall where there’s a SENDEXTERNAL event as failed because we don’t officially support recalling from external recipients. However, some SENDEXTERNAL events are due to routing out to an external smart host or to on-prem for centralized mail flow that then routes the message back into the service to an internal cloud mailbox. In most cases the recall fails, and the report shows failed as well. In some reported cases, the recall actually works but the report still shows failed (sounds like your scenario). I’m guessing you’re hitting this. We’ve a bug to fix it (hopefully by end of the year) so that recalls will work and report it correctly when mail is routed out -> back in to EXO so long as mailbox is in the cloud and internal to the tenant.

Sebjogro >>Exactly, from admin point of view we need more control.

E.g.
- Settings until how many days an email can be called back
- Force the recipients to be informed about a message recall (server side or Outlook policy)

Got it, thanks! Yes, we have both of these on our plans to give admins control over both. Hopefully by end of this year.

AA_IT >>There has to be a better way to communicate the results of the recall without a generic looking email that looks like a phishing email.

Brian >>Perhaps without any context, but this is something that arrives on your request and from a microsoft.com address. The status is probably known by the time the notice arrives though, so I wonder if that information should just be included in it, reducing the need for people to click through for more information.

Both of these are insightful points and we’re definitely looking at future options that would address both of these concerns. Too early to say what or when, but it’s definitely on our radar and we’re taking steps to prioritize tackling this.

Remi >> I've tested it and I've also received the report in English (all my non-administration tools are in French). Nothing's wrong with English, but we got regulations and such 

Yes, we’ve received a few reports of this for both French CA and Japanese and are investigating, hope to have a solution by fall if not sooner.

Jackson_John >>Hello, Is there any future roadmap item, that would enable the Recall feature to work for emails sent between two different M365 Hosted Customers/tenants? 

I'd love to, and based on feedback from you and others who have expressed the same, we are definitely looking into it, but it’ll be next year at the earliest before we could do it, assuming approval from our Legal and Privacy teams.

Mario_Mann >>Is it possible to change the language for the message recall report?

The report language should default to the language set for the client. Are you asking for the admin to be able to override the client-side language setting? Or is it not showing in the language you’d expect?

DMoenks 
Kevin>>For privacy and legal reasons the new Message Recall won’t recall messages sent to recipients outside your organization.

Dominik>>How is this implemented?

Any message routed to another tenant routes out to the Internet at which time the org headers get stripped so when it comes back if the org headers don't exist (don't match the recipient org) we don't recall. 

SW-SoCo2 >>is there any update or timeline for viewing the STATUS REPORTS for Shared Mailboxes?

We’ve been working on this one and hope to get something out by the fall.

Kreera >>Will the ability to recall a message from secondary mailboxes in the Outlook profile be made available in the future?

Same answer as for the shared mailboxes question above.

Raja_Chinndurai >>it would be nice to see the date and time of the recalled email to the addressee.

I couldn’t agree more! We actually started that way but ran into some surprisingly challenging bugs with it and thought it best to ship without it than show the wrong thing. We have it on our backlog but not sure it’ll make the cut for this calendar year, but hopefully for next year.

>>most users do not receive a "message recall" email when the sender attempts to recall. when it will be available.

Do you mean they don’t receive a Message Recall Report notification email? It’s been enabled for the WW environment since mid-April, still delayed for GCC High and DoD due to extra security, compliance, and privacy requirements. By default it’s enabled for all tenants so unless someone in your organization disabled it you should be seeing it. Run Get-OrganizationConfig | ft MessageRecallEnabled. If it’s blank (default blank = True) or True then senders should be seeing the Recall report notification email. Feel free to open a support ticket if it’s still not working.

MasonRamirez >> we manage our user's email passwords so they cannot fall victim to phishing attacks. They cannot sign in because they don't know their credentials, as we intended

Thanks for sharing your unique scenario and the problem you’re hitting with this feature as a result. Kudos to you for taking security so seriously. For the future we’re investigating and planning on an alternative approach to host the report within the signed-in client itself which would hopefully mitigate your issue. Unfortunately it won’t be available until sometime in 2024 at the earliest.

Meanwhile, as perhaps you know, you can disable the cloud-based recall and it will fall back to the classic Outlook behavior, sending a single recall status message for each recipient: Set-Organization -MessageRecallEnabled $False.  
>> I've heard if users don't have OWA enabled, they simply get an error screen 

We’ve seen reports of this, but it’s not OWA being disabled that’s the issue (we can repro it works just fine with OWA disabled); it appears to be a combination of EWS being disabled and CARs rules. We believe we have a fix for this in the works that’s rolling out. That said, to ensure user privacy we have to authentic the end-user viewing the report regardless whether OWA is disabled or not, and the same concerns you have about potentially leaking creds via OWA access would still apply here. So until we have a solution for in-client access, the cloud-based message recall probably isn’t for you and your organization, and as noted above you can disable it and fall back to classic Outlook recall behavior.
>>My complaint is that you guys change things, and don't allow users the option to just stick with the old way,

Totally get how frustrating that can be  – at least for this feature, you actually can stick to the old way:  Set-Organization -MessageRecallEnabled $False. That disables the feature and falls back to classic Outlook behavior.

I also want to note that your concerns about us changing things but giving the option to disable or revert the behavior: This is definitely a principle that’s getting a lot of air time within Microsoft, both with formal and informal communications and via processes like design, code, and compliance reviews. So while not all new features will be able to support both old and new ways, I think most feature teams nowadays are taking it into serious consideration when they introduce something new. 

Mason, thank you for taking the time to share your very valid concerns so clearly and with such civility, truly. I hear you on how frustrating these types of things can be, and on the Internet as we know it’s all too easy to fall into hostile and disrespectful discourse that just isn’t necessary and usually doesn’t really accomplish much. Thanks for taking a different, respectful tact – it’s much appreciated. Best wishes!