Tag: E-mail

Stop ‘Reply All’ Fiascos by Using BCC

Mark Morgan pointed out this reply-all fiasco at the State Department where people hitting “reply all” to e-mail messages sent out on huge distribution lists was causing problems for the State Department’s mail server. The State Department then circulated a memo threatening disciplinary actions if people continued to “reply all” to such messages.

Stupid.

The problem is not the end-user who hits “reply all” but rather the clueless sender who is including dozens or hundreds of e-mails in the CC or TO field. If you need to send a mass e-mail you need to be putting those e-mail addresses in the BCC field for a number of reasons.

First, it prevents the stupid but inevitable “reply all” messages. Hey, even I’ve accidentally hit reply all instead of just reply when responding to such mass e-mails. If the sender had bothered to take a few seconds to paste the addresses in the BCC field, it wouldn’t have mattered.

Second, in general when it comes to mass mailings I don’t need to know who else is receiving the mail. Oftentimes the result is that the recipient now has more information about who has specific authority or access to certain services than he or she really needs.

Hitting “reply all” to a mass e-mail is bad form, but it pales in comparison to sending out e-mails to dozens or hundreds of people that reveal all of those e-mail addresses in the To or CC field.

Boston College Drops Student E-mail Accounts

The Chronicle of Higher Education reports that Boston College has decided to stop offering students e-mail accounts beginning next year. Instead they have set up an e-mail forwarding system, so each student is assigned a Boston College alias that then forwards to whatever personal e-mail system the students are using.

Some of the comments reflect what seems to be the prevailing IT view in academia about university-provided e-mail accounts: if they don’t use the e-mail account we give them, we can’t be sure any e-mails our faculty/administrators send actually reach them.

Which is certainly true. Just as it is true that unless we assign all students on-campus mailboxes that they must check, we can’t be certain any snail mail we send them actually reaches them. And unless assign students to a university-provided voice mail system that they must check on a regular basis, we cannot be certain any phone calls we make to students will actually reach them.

I’ve never understood the rationale for treating e-mail communications any different in this regard from voice/physical mail accounts. Most students would find having to manage a university voice mail/physical mailbox system a major headache, and clearly a lot of students find it annoying to have universities assign them yet another e-mail account they need to check.

Given the budget crunch that many universities seem to be facing, why are they in the student e-mail business at all?

Organizing E-Mail Archives

I’ve been meaning to respond to this Merlin Mann piece on the best way to organize e-mail archives. And in Mann’s case, his answer is to not bother organizing them . . . or more accurately he never gets around to actually suggesting an organizational structure beyond throw them all in a single archive folder/mailbox.

Part of the problem, of course, is that once people start organizing e-mail they start to over-organize it. I’ve seen people who literally sorted their e-mail into dozens of different topic-based folders. Ugh.

Anyway, I have about 300,000 e-mail messages in my archive, and using a single large archive just isn’t feasible. Instead I simply organize all mail by year and then month. So my Thunderbird archives look like this,

2007
01
02
03
04

etc.

This keeps each archive folder down to a reasonable size while also allowing quick searching just by selecting year/month subfolders (searching on e-mail dates don’t always work because I have e-mail sent or received by systems that did not properly report the date).

It’s a nice compromise between no organizational system at all and some absurdly complex topical/project-based archiving system.

Five Simple Rules for Keeping an Empty Inbox

Okay, I’m not even sure I want a completely empty inbox, but Download Squad has some useful suggestions for downsizing your inbox,

  1. If you don’t need to read it now, it shouldn’t be in your inbox.
  2. If you’ve already responded to it, it shouldn’t be in your inbox.
  3. If it comes from a known source (some person, retailer or mailing list that sends you mail more often than once every few months) it should be labeled automatically.
  4. No one needs to look at their own inbox more than once an hour (and for many, once every 2-3 hours).
  5. To borrow from the cult of GTD, re-factor constantly and mercilessly

The article expands on how to actually do each of the above. For my part, I receive so much e-mail that I’m happy if I can keep my inbox under 100 e-mails.

E-Mail As Key to Collaboration

The Central Desktop Blog has a companion piece to its previous piece on the advantages of using e-mail as a collaboration tool. This time around, the developer is concerned without pointing out e-mail’s alleged failings.

The first problem with e-mail is key and one that any collaboration tool should overcome — “Email is silo’ed”. When you have multiple people working on a project, each of them have pieces of the puzzle in their inboxes, but none of them has access to each other’s pieces. This is the major flaw in e-mail.

The way around this is to use collaboration software that makes it easy for individual users to share their piece of the puzzle on a project/task by project/task basis. I use a couple of collaboration tools on a daily basis that are designed to do just that and do a remarkable job of using e-mail to collaborate.

At the extreme, Central Desktop is right — there are still materials that end up staying in the inbox rather than ending up in the collaboration system, but sometimes that is also a good thing. The key is to trust the users to know what needs to go in and what needs to be left out, and, frankly, if you can’t trust people to make those sorts of decisions it’s not likely you’re going to have a successful collaborative experience regardless of the tool you’re using.

Central Desktop’s second argument is that e-mail is inherently insecure. Yawn. Every application is inherently insecure in the way that Central Desktop means it,

I argue that email is the single most vulnerable point in any organization’s security policy. It takes two seconds to send a confidential document to anyone or any group in the world.

Right, and it takes five seconds for me to download that confidential document and mail it to anyone in the world. It takes me 10 seconds to take a screenshot of that document and mail the screenshot to anyone in the world. It might take me 15 seconds to copy the document or screenshot to a flash drive and send it to anyone in the world once I’m outside the corporate network.

If I can see it, it ain’t secure — end of story.

The rest of Central Desktop’s complaints simply indicate what happens when you’re not running a collaboration tool that uses e-mail as a central collaboration method. So, we learn that “Group email is really complicated [to install and configure]”, “Email is not a document manager,” and “Email communications do not correspond priority.”

Applications that use e-mail as a central organizing tool for collaboration solve all of these problems.

Personally, I’m a big fan of Steve Krug’s maxim for web design — “don’t make me think!” The best design/user interface is one in which the user almost forgets that they’re interacting with a user interface. The e-mail collaboration tools I use come close to achieving that, whereas the sort that Central Desktop sells always require me to devote significant brain cycles to figuring out how I’m going to do this or that function.