What do I do when my Journal Mailbox gets full?

If the number of emails in the journal mailbox gets excessive, or the amount of storage they take up starts to cause problems, there are a number of actions that can be taken to resolve the situation.

First, check that the fetcher is working. View active jobs by selecting the System Status link listed under the Status tab.

This screen shows that there are no active processes on this system.  If the fetcher was supposed to be running, this shows it isn’t.

If the fetcher is running, click on the details symbol (the magnifying glass).

The details screen will show how many emails it picked up in the current hour (1), and how many it has fetched today (3).  In the MailboxState field the number of emails in the journal are listed.

If the fetcher isn’t fetching (and you don’t know why), a good way to debug it is using the Health Test.  You can run the health check from either the Status → Full System Health Checkup, or from the fetcher configuration where it is a green check symbol under the actions column.

If there is a failure in the tests, you can find more information by clicking the word “failed”.  Like all the health checkups on the system, once one test fails, the following tests aren’t run, and also show as “failed” even though they weren’t tested.
One note on the “log in” test.  Sometimes it fails for iMap protocol even though the mailbox name and password are correct.  This is fixed by restarting the iMap services on the email server.

Immediate Delete vs. After Backup Delete

The fetcher can be set to either delete the mail from the journal mailbox immediately, or do it after the mail has been backed up on the archiver.  The latter is, as stated on the configuration screen, safer, because, should a catastrophic event occur that causes the loss of the archiver, you would be able to recover the backed up email from the archiver’s backup, and the un-backed up email from the journal mailbox.  But sometimes the journal mailbox gets too full to be totally safe, and changing the fetcher to delete the email immediately is required.

Another thing to check, if you are deleting the emails after they are backed up, is to make sure the backups are running.  The Backup tab → Backup History screen will show if the backups have been running successfully.  If they aren’t successful, then that problem needs to be resolved (and the fetcher set to Delete Emails Immediately until it is).

Some virtual machines do not do backups within the archiver, making use of the host machine’s snapshot to use as disaster recovery.  In this case, the fetcher should not be set to Delete Emails Once Backed-up, because no backups on the archiver itself are performed.

Fetcher Protocol

Fetchers can be set to use either POP3 (Post Office Protocol) or IMAP4 (Internet Message Access Protocol) and their secure versions, sPOP3 and sIMAP4 to communicate with the email server.  IMAP  is usually more efficient, as it batches activities.  However, when a mailbox gets a large number of emails in it (experience shows impacts around 80,000 or more) it gains so much overhead that it is more efficient to run POP in these situations.

The protocol is set in the configuration of the fetcher (see screen in previous section – in that example the pull down menu is set to sIMAP4).  You should stop the fetcher, make the change, then restart the fetcher if you are changing protocols.

The email server needs to be set to use these protocols and have them activated.  Just because an email server can use the protocol, doesn’t mean it is configured to use it.

Create another fetcher

It has been observed that some email servers have performance problems when a mailbox gets too full.   One recent case had a server receiving around 10,000 emails an hour into the journal mailbox, but the fetcher was only getting 3000 out of it.

In situations like these, you can set up a new journal mailbox, create a new fetcher to receive the new email coming into the server, and leave the old fetcher to clean out the original journal mailbox.  In the case just described, the new fetcher had no trouble handling the 10,000 emails an hour, while the old one process a steady 3000 emails an hour that the email server was passing to it, until the journal mailbox was empty.

Backups good, email not deleting

Although the configuration says “Delete after backup” or “Delete immediately” the truth of the matter is that the Orca doesn’t actually delete any email from the email server.  When the conditions are met (either after downloading or after backing up the email) the Orca sends a message to the email system to delete the selected email.  It waits for a confirmation that the message was received by the email system, and then never considers those emails again – the Orca has done it’s job, it has requested them to be deleted, and the request has been received.  If the email server does not delete them, the Orca is neither to blame or even informed that they didn’t delete.  This problem lies on the email server and is outside the scope of this document.

But even if it is an email server problem, you can get the Orca to request the email be deleted again, but only if it is set up correctly.  That set up is as follows:

• The fetcher must be set to POP3 or sPOP3 protocol
• The deletion must be immediate
• The fetcher must be reset completely.   To do this, from the fetcher list screen, press the blue button.  This will bring up a screen with 2 reset options.  Resetting completely will force the fetcher to attempt to download all the email in the Journal Mailbox.  If the email has already been downloaded, a delete message will be sent back to the email server.  (If it hasn’t been downloaded, it will be, and then the delete message is sent.)

If you have the fetcher set to “Delete after backup” because, as it says, it is safer, you might want to follow the previous section and create a new journal receiver and fetcher, let the system do a backup, then follow these instructions on the old journal mailbox, since at that point, they should all be backed up, and any non-backed up emails will be in the new journal mailbox under the control of the new fetcher.