28 Feb Email archiving methods explained: Journaling Vs. mailbox collection
If you’ve just downloaded MailStore, you’re no doubt primed and ready to start hitting “next, next, next” to get up and running as soon as possible. Before you do however, it is worth just taking a moment to think about your requirements in a little more detail.
We see all sorts of weird and wonderful variations to cater for different customer scenarios, but in most cases you’ll need to consider which combination of “journalling“, and direct connection to individual mailboxes you’re going to use to archive your email.
Method 1: Journaling
Despite the fact it’s a feature of Exchange, it’s a term that when I mention it to customers, still causes those momentary silent pauses so a quick clarification before I start. In this context, it’s the process of using another dedicated mailbox to store perfect, unmodified copies of every message that passes through the mail server (including messages sent between users internally).
MailStore can archive this mailbox in a specific way, periodically polling it and sorting the messages it finds based on the local senders or recipients it finds that match its users email addresses.Once archived it would usually delete out the contents from the journal mailbox. As a result, this journalled mailbox should only ever contain messages that haven’t yet been archived.
So a quick look at why journaling may or may not be a good idea for you…
- Compliance – this is the only way to ensure a copy of every email ends up in your archive store. Particularly if you need to keep mail for long periods because of industry legislation, you’ll definitely need to journal.
- Regularly updated – In large deployments of 100’s of users it may not be practical to check all those mailboxes very regularly as it would take too long in most cases, but using a journalling account you can keep your archive updating every few minutes should you wish.
- Sorting – this method automatically reads the information in the email headers to sort and allocate messages to the relevant users
- Low overheads – it’s an efficient way to trickle email into the archive all day long using a single archive job
- Historic mail – journalling only archives new email from the time it is configured, it’s not possible with this method alone to archive old existing messages (although you can still upload PST’s)
- Mailbox management – there’s no direct connection to users mailboxes so it’s not possible to prune older, already archived messages. Used alone, a Journal job wouldn’t tackle the issue of users keeping hold of large volumes of email
- Folder structures – Journaling will only create in an incoming and outgoing folder for each user. This is fine if users want to retrieve mail by searching, but they won’t be able to browse the folder structure they’ll be used to seeing in Outlook.
Method 2: Direct mailbox collection
The other archive option available to you is configuring MailStore so it connects to your mail server as either a power user with the ability to access all of your accounts in one go, or with the credentials of each user to access your mailboxes individually.
In the case of hosted email services, this may be the only practical option available to you, but for the purpose of this post I’ll stick to talking about options relevant to a server located on-premise.
The pros and cons of connecting directly?
- Historic mail – If you want to pull in some existing mail, so anything older than this point in time, this is really the only effective way to do it quickly and the way we’d recommend you do it.
- Mailbox management – Connecting to mailboxes individually gives you the ability to purge messages once they’ve been collected. This is how you’d automatically manage mailbox sizes to prevent them from becoming overloaded.
- Folder structures – Connecting directly enables you to synchronise the folder hierachy and essential if users wish to have the ability to browse their folders exactly as they’re used to seeing them in Outlook.
- Exclusions – unlike journalling which would simply take a copy of everything, you’ll also be able to add exclusions so certain folders aren’t archived when your jobs run.
- Message locations – As users move messages between folders in Outlook, connecting directly synchronises the locations with those stored in the archive so emails are always where you expect them when you use the browse view in MailStore.
- No good for compliance – running collection jobs periodically allows a window of time when users could potentially delete or modify email before they’re archived. This means you can’t class this method as suitable for audit purposes.
- Job times – the main drawback on larger deployments is that just the time it takes to connect and archive a large number of mailboxes can be lengthy, this restricts this type of job to being suitable for running typically once a day only.
- Slow initial import – when you pull in your historic email, you’re likely moving a significant amount of data so this is always going to take quite a while due to network/ bandwidth limitations. Of course you only need to do this once.
- Network load – the overhead of connecting to multiple mailboxes is much greater than polling a journalling account and usually something we see users schedule outside of working hours.
So that’s cleared it up then?
While I’ve written this as a compare and contrast article, in actual fact, ideally you won’t have to choose. My advice is that if you can, you configure MailStore to run both a regular journalling job, and a daily mailbox collection one.
Using each method really does provide you with the best of both worlds, in summary, the combined headline benefits being:-
- Fully audit compliant
- Protection against message deletion/ modification
- Ability to browse folders AND to search the archive
- Automated management of mailbox sizesa
Hopefully you’ve found that useful but if you’d like to chat over your requirements please feel free to get in touch. Likewise, if you liked the article or have any suggestions go ahead and use the comments section to let us know.