I recently had the opportunity to work with the Novell GroupWise suite. It was a painful experience in every respect. GroupWise is stuck firmly in the Microsoft Mail era of design and UI, and administering it was about as much fun as eating sand. Most GroupWise shops have become accustomed to GroupWise’s message recall feature, which lets a sender reach out and delete a sent message from recipients’ mailboxes (provided that the recipient hasn’t read it yet). This capability can be a real lifesaver to people who tend to type faster than they can think, or who accidentally send a confidential or sensitive message to the wrong internal recipient. So, the one single question I see every time a company is considering moving from GroupWise to Exchange Server is this: How does Exchange implement message recall?
Long-time Exchange administrators already know where I'm going with this. Message recall is one of those features that seems simple on its face, but proves deceptively difficult to implement in a way that pleases everyone. The basic scenario is easy: Alice sends Bob a message, then later she decides that she wants to take back what she wrote. This feature seems like it would be easy to implement: Give Alice's client a "take it back" button that causes the sent message to be removed from Bob's mailbox. This is essentially what GroupWise does. On the Exchange front, this scenario is when the fun starts because all of the possible solutions have problems.
Perhaps recall could be implemented as a bit of code that removes a recalled message from recipients' mailboxes. At first blush, this seems like it would work—until you consider all the places that the message might still remain after being "removed." It would, at minimum, still be in the sender's Sent Items folder. It wouldn't remove copies of the message that had been cached by a client, such as what happens with Outlook in Cached Exchange Mode or with an Exchange ActiveSync client. GroupWise has limited support for these features, so they’re not obstacles in their world.
Another, more involved, approach is to do what Exchange currently does: When you recall a message from the client, a special recall message is sent to the recipients. If they accept it, their clients remove the recalled message. This process has the advantage that it properly handles cases where the message is cached by the client—provided, of course, that the client supports the recall message in the first place! However, the big disadvantage to this approach as implemented by Outlook is that the recall message isn't compulsory. Most users (me included) will see a recall message as a spur to read the original message to find out why it was recalled—the opposite of the intended effect!
All of these approaches share some other problems. They only work with a single mail system. When the message goes outside the organization—which is often when you have the greatest need to recall it—all bets are off. This limitation might be a blessing in disguise because a universal recall system that did work properly would represent a tempting avenue for misuse and external attacks. In addition, companies that are subject to data-retention requirements might face sanctions for failing to retain messages properly because users recalled them.
There are legitimate cases where an administrator needs to recall a misdirected message. Unfortunately, we still don't have great tools for this kind of recall. Exchange 2007 provides the Export-Mailbox cmdlet, which lets you search for messages across multiple mailboxes and archive or delete those that meet the criteria you specify. Export-Mailbox thus provides a basic administrator-level way to search for and remove all copies of a particular message, which is good enough for most requirements.