SSRouter - Error moving message. Cannot Store document...

Problem

On a Standard Installation of SpamSentinel, the SpamSentinel Router process is constantly throwing errors and many messages are remaining stuck or delayed in the scan.box databases while others are delivered.  The error shown on the Domino console and in log.nsf is:

SSRouter - Error moving message  Cannot store document - database has too many unique field names.  Please set the 'Allow more fields in database' option or ask your administrator to compact the database....

Background Information

This can happen to any Domino server over time as mail messages often have non-standard field names in the SMTP header. Over time this can cause the UNK table in the .nsf structure of mail.box to become full. Eventually, if a mail message contains any never-before-seen field names, the message will not be able to be moved into the mail.box file. Domino has some built-in processes to reduce the size of the UNK tables in mail.box files but these are not always effective.

It is most likely that only certain Spam mail messages are failing to deliver. Most non-spam mail messages will continue to deliver to users even when these errors are happening. This problem can go unnoticed for some time unless someone sees them in the Domino console, log.nsf or through the error-reporting system we have here at Maysoft.

The SSRouter will keep re-trying to move the message from Scan.box to a Mail.box.  SSRouter uses different mail(x).box files for each message if more than mailbox files are in use on the server.

If even one of the mail(x).box files does not yet have a full UNK table, messages can continue to route though errors will be thrown whenever a 'problem' message is attempted to be moved to a mail file which does not already contain the new field name and which has a full UNK table. Such messages may be re-tried multiple times and eventually be routed out through a mail.box with a less full UNK table.

Solution

From our experience, there are two ways to deal with this issue. Both require operating-system level access to the server.  

Though these two sets of actions should be equivalent, we have had fewer problems with simply replacing mail.box rather than trying to compact it.

1. Replace the mail.box

a. Shut down the Domino Sever service
b. Use the operating system to rename the problem mail.box as mailold.nsf
c. Launch Domino again. Domino will create a new mail.box for itself on startup.
d. Use the Notes client or the Domino Administration client to open the mailold.nsf database
e. Copy and paste any undelivered mail documents from mailold.nsf into the new mail.box. You can usually ignore messages which are 'dead'
f. Delete the mailold.nsf

2. Offline compact of mail.box

a. Shut down the Domino Server service
b. Use the command-line syntax of ncompact.exe to perform a copy-style compact of mail.box while Domino is shut down
c. Launch the Domino Server service.