Follow Up Improvements for the “New” Message Recall
In February 2023 (released in April 2023), Microsoft announced a new message recall feature for Exchange Online. At the time, Microsoft said that 800,000 people attempted to recall messages daily at a 40% success rate, which clearly meant that many experienced failures at a time when they might be stressed about sending an inappropriate, incomplete, or otherwise problematic email. A radical overhaul was needed and that’s what Microsoft delivered with a cloud-based recall facility where a background agent rather than Outlook clients managed the recall process.
Microsoft reckoned that the new approach increased the success rate to 90%. Now they’re back with more enhancements to smoothen some of the rough edges for the initial implementation, described in an August 22 blog post. The update should be available in your tenant. Let’s parse out what’s happening.
Two important points about message recall deserve some emphasis. First, the new message recall continues to be a cloud-only feature with no equivalent available for Exchange Server. Second, message recall only works inside the tenant boundary. In other words, you can recall messages sent to people in the same Microsoft 365 tenant, but once Exchange Online transfers email to another tenant or another email service, recall becomes impossible. Nothing has changed in these respects since the original April 2023 release.
The Question of Cross-tenant Message Recalls
Recalling email within Microsoft 365 is technically possible. All bets are off when email passes to other services. I’ve heard various explanations as to why Microsoft can’t recall email sent to other tenants. GDPR and other “privacy and legal reasons” are cited, but I can’t see why this should be the case if the sender wishes to recall their own message.
An analogy can be advanced that when Exchange delivers a message to someone, it’s like the postal service dropping a letter into the addressee’s mailbox. No one would countenance the sender coming and retrieving the letter they sent. Another case is that someone could receive and act upon information in email that is later recalled, and if the email no longer exists in that person’s tenant, then no trace of why they acted is available. The issue might therefore be more centered around compliance and record keeping than privacy.
Another thing that struck me is the possibility of an attacker attempting to exploit the same kind of technique described at the recent BlackHat USA 2024 conference when they sent a message to a user that was later used to change the results returned by Copilot for Microsoft 365 to convince the user to transfer money to an incorrect account. If cross-tenant message recalls were supported, the attacker could use message recall to remove traces of their email. These kinds of attacks are in their infancy
Message Recall Updates
What has changed since the first release include:
- Expanding client support for the new message recall from Outlook classic to OWA and the new Outlook for Windows (aka the Monarch client). Message recall is available in the advanced options menu for sent messages.
- Improvements when recalling messages sent from shared mailboxes. In other words, message recall works.
- Implementation of a setting to set the maximum age for messages that can be recalled (new). The default is 365 days, and the setting can vary from 5 minutes to ten years. Recalling even a year-old message sounds like an exercise in futility to me. If someone attempts to recall a message older than the tenant threshold, they receive email to say that recall isn’t possible.
- Support for external round-trip routing (new).
- Optional recall notifications for message recipients (new).
One of the things that message recall still doesn’t do is capture audit events when people attempt to recall messages. That’s a gap that should be closed.
Message Recall Notifications
Recall notifications deserve some discussion. The previous implementation silently removed messages from recipients’ inboxes and left no trace that the message had ever reached inboxes. In many cases, this is exactly what the sender wants to happen, especially if they had sent some confidential information in error.
However, if someone reads a message that subsequently disappears, it can create some doubt about what happened and lead to questions to the sender (“Did you send me something”) or help desk. The new implementation addresses the situation by allowing tenants to enable message recall information for recipients in two modes:
- For all recalled messages.
- For read recalled messages only. This seems like the right setting to use, if you’re concerned about the disappearing recalled messages syndrome.
When either mode is enabled, recipients of recalled messages receive email about the recall (Figure 1).
External Round-trip Routing
Many organizations choose to use external services to perform some processing on outbound messages before passing traffic back to Exchange Online for delivery. The service might take care of message hygiene to check that email doesn’t contain malware, or it could do something to messages before they leave the organization, such as updating the body with a corporate email signature.
The original message recall implementation couldn’t deal with recall requests when messages passed from Exchange Online to an external service because the target messages had left the tenant. The upgraded message recall can recall messages that pass through an external service for processing.
Organization Configuration Settings for Message Recall
A bunch of organization configuration settings control how message recall works. The default values are:
Get-Organizationconfig | fl *recall* MessageRecallMaxRecallableAge : 365.00:00:00 RecallReadMessagesEnabled : MessageRecallEnabled : MessageRecallAlertRecipientsEnabled : False MessageRecallAlertRecipientsReadMessagesOnlyEnabled : False
The settings are exposed in the Exchange admin center. Figure 2 shows the same setting values for the settings reported by PowerShell above. You can see that the settings to enable cloud-based message recall and to allow users to recall messages read by the recipient are both set whereas no value is set in the organization configuration. This means that the tenant uses the default setting (true).
If you prefer, you can update the settings with PowerShell. The only thing to remember is that if you want to enable message recall information for recipients and limit the generation of notifications about message recalls to people who have read recalled messages, then both the MessageRecallAlertRecipientsEnabled and MessageRecallAlertRecipientsReadMessagesOnlyEnabled settings must be true.
Set-OrganizationConfig -MessageRecallAlertRecipientsEnabled $True –MessageRecallAlertRecipientsReadMessagesOnlyEnabled $True
If you attempt to set MessageRecallAlertRecipientsEnabled to false and don’t update the MessageRecallAlertRecipientsReadMessagesOnlyEnabled setting to match, Exchange Online will update the setting for you:
WARNING: MessageRecallAlertRecipientsReadMessagesOnlyEnabled is set to false automatically because MessageRecallAlertRecipientsEnabled is set to false.
Recalling is Easier Than Before
Hopefully, you never make a mistake and never have to recall a message. If you do need to recall, hopefully the message will be embarrassing rather than career-limiting. The edges taken off the initial implementation of cloud-based message recall in Exchange Online make it easier to live with, even if you do get into the situation of having to find the message recall option.
