The Downsides of Stubbing (And When You Should Ignore Them)

Because of its introduction in GroupWise 8, stubbing is getting a lot of attention lately. The idea behind stubbing is to display email in a user's inbox, but have the actual email content reside outside the email server. The benefit is that you get to keep your messaging system relatively streamlined, but still give users easy access to those stored messages.

This sounds pretty good, but a bit of Googling may have you wondering about the value of stubbing. Although there are some mixed opinions about stubbing, I fall into the “pro-stubbing” camp. Let me re-phrase that. I'm pro-stubbing when stubbing is done correctly.

The criticisms of stubbing are usually rooted in poor uses of stubbing. It's kind of like saying you shouldn't exercise because you might get hurt. Well sure, if you don't warm up properly, you might end up with a pulled muscle. But, does that mean you shouldn't exercise at all? (If you're looking for an excuse to skip a trip to the gym, don't answer that.)

Here's a good rule of thumb: Stubbing works well for large items and aging items. Anything else, and you're not using the technology the way it was intended.

For example, here are some of the “downsides” you might read about stubbing:

1. A stubbed message will take longer to open then a non-stubbed message.

Well … ya, it will. That's because the message resides on non-local, cheaper/slower storage. That's why it makes sense to store aging information (which isn't accessed as frequently) or large items (which one might expect to take longer to open).

2. A new point of failure is introduced. If the stubbing agent or the secondary storage become unavailable, stubbed items can no longer be opened.

There are two points to consider here. First, the instability resulting from keeping massive amounts of large and aging messages in the live system is a far greater problem than the risks introduced by a secondary storage system. Plus, even if the secondary storage becomes unavailable the organization is only temporarily losing access to aging data, not the mission-critical, newest mail.

3. Stubbed items can only be opened using the native client. For example, a GroupWise user can access their mailbox via GroupWise and the stubs will work just fine; but, if a user wants to use some other mail client, like Thunderbird, to access their GroupWise mailbox, the stubbing won't work.

It's true that you can access the live mail using any mail client via standard protocols like POP and IMAP and get basic functionality; but certain features specific to GroupWise -- like stubbing or proxy access – won't work. However, if you're using something like M+Archive, which is policy-based, it isn't an all-or-nothing scenario. You don't have to apply the same policies to all the users, so you wouldn't have to implement stubbing for users who access their mail via a POP or IMAP client. Those users could still access their archives using WebAccess.

Read between the lines

If you find someone who isn't a fan of stubbing, check the source. Is it a solution vendor whose product doesn't support stubbing? They may well be downplaying the benefits of stubbing to justify this missing feature.

Here's another gem I've come across: “To compensate for its inherent instability, Exchange has something called stubbing that is being introduced into GroupWise.” They'll then make to leap to imply that Exchange uses stubbing because it's unstable and, because GroupWise now offers stubbing, it must be unstable, too. Not true.

Here's the upshot: Stubbing addresses a common and serious problem, i.e., that users keep too much mail. This uses a lot of primary (expensive) disk space and reduces the performance of the mail system. When used intelligently, stubbing can bring huge storage management benefits by reducing the size of your mailbox store, thus improving the performance of your live mail system and reducing the amount of time it takes to perform backups.

In my next post, I'll share some tips for getting the most out of stubbing.

– Daniel Bigras
Dan Bigras is a Technical Solutions Architect at Messaging Architects, and all-round nice guy.