ixteen years after Outlook first appeared to make the “Reply All” the biggest trap that users can fall into in terms of sharing email with people whom they didn’t intend, Microsoft Research produced an Outlook add-in called “NoReplyAll” to bar recipients from using the reply, forward, or reply all options for messages they receive. The add-in has been around for a while and the latest version is 3.14 dated 2 August 2013. It is part of the work Microsoft Research is doing in the desktop area (you can gain a sense of their activities through their support forum).
I might be a tad harsh in blaming Outlook for inflicting the misery of reply all on us. Other email clients had this functionality before Outlook 97 appeared, but given the ubiquitous nature of Outlook today, it’s fair to assume that more Outlook users have had the unique experience of realizing that they have just replied to every person on a large distribution list to share thoughts and feelings that ould have been better kept private. Or those that have caused an “email storm”.
Microsoft employees share the same fallibilities as the rest of us and I bet that the Microsoft Research project is a response to similar experiences inside Microsoft of just how easy it is for emailed information to end up in unwanted places. This isn’t the only attempt to solve the problem. Another example is Code Two Software’s “Reply All Reminder” tool.
Of course, Microsoft has long used Information Rights Management (this information about how Microsoft uses IRM internally goes back to Office 2003) to protect sensitive messages, reputably because Steve Ballmer was incandescent at how so much email leaked to journalists and others outside the company. IRM is very effective, but it requires quite a lot of administrative effort to plan, deploy, and manage, and so it hasn’t achieved as much success as you’d imagine in the market. Of course, IRM is easier inside Office 365 because Microsoft does the heavy lifting behind the scenes and it will be interesting to see if the technology becomes more widely used over the next few years.
In any case, the add-in supports the 32-bit and 64-bit versions of Outlook 2010 and 2013 when connected to an Exchange server (on-premises or cloud). The following text describes its use:
“The primary function of this add-in is to add a few buttons to the Outlook ribbon to prevent people from replying to all the recipients of your message or forwarding it, etc. The add-in uses a facility built into Outlook and Exchange that is more lightweight than information-rights management but is not exposed in the existing UI. The add-in also includes a check for common email errors, such as omitting attachments or subject lines.”
All very good stuff. The implementation is simple too. Three new buttons appear in the Outlook menu bar to disable the reply, forward, and reply-all options for a message and a set of default options can be set too. One limitation is that the options to block replies and forward can only be set for messages created in a separate window - you can't apply them to replies created inline. The block options for received messages works very well, as long as the recipient uses Outlook, in which case they’ll be told that whatever options have been blocked are unavailable when they attempt to use them. Of course, it's not IRM so recipients can cut and paste text from a message and send it on to someone else, but they have to take an explicit action to do this - hopefully one that involves some thought.
You might be wondering why it has taken so long for Microsoft to come up with a solution for a problem that afflicts so many people every year. Well, the problem with anything that seeks to protect content circulating in email is that it is relatively easy to come up with a mechanism that works well for a single client type but horribly complex when multiple clients are involved. Even though Microsoft has made IRM simple to use with Exchange Online, IRM-protected messages still can’t be read on all EAS clients (Windows Phone is a notable exception).
The “facility built into Outlook and Exchange” strongly indicates that MAPI properties are involved. I browsed through some messages with MFCMAPI to see if I could spot how the controls were implemented but the obtuse nature of MAPI hid those secrets pretty well. Full-blown MAPI clients like Outlook know how to respect MAPI properties but clients that use other protocols do not because the protocols that they use might not even support an equivalent. So while I was able to restrict messages sent to Outlook users, recipients who read the messages on Exchange ActiveSync (EAS) clients, Outlook for Mac (which uses Exchange Web Services (EWS)), and Outlook Web App all were cheerfully able to ignore my wishes.
So, if Microsoft wanted to allow users to restrict the ability for recipients to reply all to a message, they would have to update the EAS and EWS protocols and then provide new versions of Outlook, Outlook Mobile (Windows Phone), Outlook for Mac, and Outlook Web App to respect the settings. And that’s just the start because we haven’t yet discussed how many versions of these clients need to be retrofitted. As you probably know, we’re not great at deploying new client software, especially desktop versions, and the feature wouldn’t be much use until clients that supported it were widely deployed.
Another issue is that some arrangement would be needed to enforce these blocks when messages travel outside the boundary of the Exchange organization. On the other hand, making sure that external recipients cannot reply or forward a message might not be important because once a message has left your organization, it becomes someone else's problem. Securing agreement from multiple email vendors as to what flags should be transmitted and how those flags should be processed is likely to take a lot of time and effort with no guarantee of success.
Microsoft could make all the necessary changes at its end to upgrade its clients but we’d still be left with the fact that millions of mobile EAS clients on devices such as iPhones would remain blissfully unaware of the restrictions. In effect, Microsoft has zero control over how EAS licensees incorporate EAS into their clients and most mobile device vendors concentrate on making sure that their clients can create, send, and receive mail, process calendars, and deal with tasks and contacts and no more.
Interesting as the NoReplyAll research project is, I fear it will remain a research project. The sad fact is that there are just too many moving parts to fix before reply-all can be eradicated, even if we wanted it to be.
Follow Tony @12Knocksinna
