Loose E-mail, Fast E-mail

(With apologies to Melville) The Wall Street Journal notes a career-enhancing moment by an executive at Carat International, who sent an e-mail with confidential information about restructuring (= large-scale firings) to the entire firm, rather than the (more limited) intended recipients. Fortunately, Carat’s IT department managed to “pull back” the message (known to geeks as “if unread, then retract”; when I worked at Lotus, this was among the most-requested feature additions by customers, and they’ve finally added it). Unfortunately, AdAge.com got a copy and published it.

This isn’t the first such goof. In fact, a classmate of mine accidentally sent his tale of summer associate leisure to a ream of his colleagues at Skadden Arps rather than just his friend. (It worked out fine for him, but one can only imagine the adrenaline shot on realizing the goof.) It reinforces that information is exceedingly slippery in an age of digital networked communication.

The WSJ writer, Sarah Needleman, proposes some technical ways of providing the pause that refreshes (or causes reflection) – essentially, having one’s e-mail client ask “Are ya sure?” before doing Reply to All or sending to a mailing list. There are two potential problems here. The big one is that people will immediately try to turn off this annoying feature. (Think about Vista’s user account controls.) No one likes it when Notes or Outlook acts like your mom. The second is that such a feature needs to display more information in order to be valuable. If it just asks “Do you want to send to all?”, the answer is, “Of course! That’s why I clicked Send!” The feature ought, therefore, to list all of the recipients when it nags you. There are technical reasons why this might not work – imagine if it’s a mailing list, or if the client is offline and doesn’t have the ability to expand a group into a list – and people are likely just to click past the warning anyway.

Speed is the antithesis of reflection. The brilliance and challenge of e-mail is that it enables near-instantaneous communication. We tend to write things we shouldn’t, and to send them to people we shouldn’t.

So, what if we used technology to force a period of reflection? What if your client let you impose a “cooling-off period” – such that it placed every sent mail in an Outbox, and then sent it after a period of time that you determined via configuration settings? (This works similarly to how mail clients such as Notes and Thunderbird handle things when you send mail when not connected to the Internet.) What if your company made a 60-minute cooling-off period mandatory? Or should we just let instances like this act as cautionary tales, changing perhaps our internal norms but not our mail clients?

4 Responses to “Loose E-mail, Fast E-mail”

  1. I am one of those idiots who accidentally used the reply all when I should have used reply. While the result was mild amusement on the part of the recipients, it was nevertheless a “close call,” as I had added a humorous social note to a business email.

    Since that time, I’ve adopted a distinctly low tech solution to the problem. It requires no software upgrades or server setting changes. I simply try to avoid sending e-mails that I would be unhappy to see on the front of the World Weekly News.

  2. Cool off period would be a nice addition, but it comes with a few drawbacks as mentioned. The instantaneous message transfer gets interrupted. Having set up quite a few internal and external mail systems, I’ve often come across delays in transfers that could essentially be used for a retraction, but that wouldn’t really solve the problem.

    Maybe one needs to look at this slightly differently – introduce a delay on multiple reciepients or mailing lists. This would probably be much more productive but would require each and every client to be updated with this feature as it is often the clients that have the list of reciepients. Of course this could or should also be applied to server side MTA’s when sending to lists handled by these.
    This approach would leave the instantant message to one person live and prosper but limit the broadcasting facility with an option to retract. You essentially get the best of both worlds.

  3. I’ve also sent the occasional accidental e-mail. It’s even better than coffee as far as stimulants go.

    Kent, I think that’s an interesting idea. The one-to-many system initially introduced in RFC821 is the cause of a lot of problems (as well as offering tremendous efficiency, of course). It’d be neat to have an algorithm implemented by the server-side MTA that held the message. The challenge might be implementing functionality that would provide the retract mechanism – I think Domino still uses the mail-tracking system to do this, and it creates a fair bit of overhead.

  4. Now thats funny, One-to -many was supposed to be a solution. I think there should be a confirmation check to ensure that the sender really wants to opt for one to many or one to one before any mail is sent.