When you’ve got to deal with as much information as everybody in a large company does, most people write Inbox rules to redirect DLs to their own sub-folders. They then group the folder “By Conversation,” which lets them quickly read the threads of interest. But most importantly, it lets them ignore the ones that do not.

If you don’t yet use these techniques to help you manage your own mail, you will love yourself for starting. I may follow up with a post in the future about that, but it’s a staple in email management in any large company.

When you BCC a distribution / discussion list, that mail break the inbox rules of everybody subscribed to the DL. That includes your boss, the person managing the sr. exec’s mailbox, and the person just about to jump off a cliff from email overload.

So aside from being rude (people set these rules up for a reason,) it doesn’t actually solve the problem you might think it does. Although it is nearly always done with the intent to minimize “noise,” noise in a person’s mailbox is much worse than noise on a distribution list.  Inbox rules are the single most effective means that we have to manage the massive stream of information that flows through the company.

BCC to “take Offline”:

Please do not use BCC to take a thread offline.  Instead, a reply-all with “taking this offline” will suffice. The alias knows that the thread is being addressed, and further conversation is unlikely to follow. In a follow-up mail to the person, you might provide the information you planned to originally. For those that batch their reading of the alias, they probably don’t even care about this specific thread, and will skim right past it.

If the conversation continues (i.e.: despite the intention to take offline,) then it was clearly of interest to the DL. No amount of BCCing will prevent the conversation from ending on its own schedule.

When you’ve resolved the issue, people often appreciate it when you follow up with the main thread with the details of the resolution.

BCC to “Redirect to another Alias”:

Please do not use BCC to redirect a thread.  Instead, a reply-all with “please take this up on the alias.” The alias knows that the thread is being addressed, and further conversation is unlikely to follow. For those that batch their reading of the alias, they probably don’t even care about this specific thread, and will skim right past it. Aaron Lerch recently wrote a cool macro to unfortunately automate exactly this scenario.

BCC to prevent “Reply All”:

Please do not use BCC to prevent Reply-Alls.  There are very few situations when limiting “Reply All” makes sense on a distribution / discussion list. If a conversation starts or continues (i.e.: despite the intention to prevent Reply-All,) then it was clearly of interest to the DL. No amount of BCCing will prevent the conversation from ending on its own schedule.

A DL isn’t there to be people’s internal version of the LazyWeb — so I disagree with attempting to prevent Reply All. A thread will continue until it runs out of steam – in which case no amount of prevention will stop it. If it was a boring question in the first place, you don’t have to worry about a reply-all storm anyways.  DLs that are highly populated involuntarily (i.e.: organizational aliases) should have the send-to permissions restricted. But since techniques exist for managing mail to DLs, a Reply-All storm really doesn’t matter.

Case in point: An internal alias recently suffered a meltdown. With rules in place, my only comment was “weird, why do I have 3000 mails in that folder all of a sudden?”

In the very unlikely chance that you have a good reason to prevent a Reply-All, Scott Hanselman’s suggestion (or an Outlook NoReplyAll form) is probably the best bet.

BCC for unknown reasons:

Please do not use BCC unless you have a good reason to.  Instead, send a message saying, “Please reply directly to me,” if that was your intent.