10.9.1 MTA Text Databases

MTA use of sleepycat databases is being deprecated because of the instability it introduces in Messaging Server deployments. (Note that sleepycat will not be removed in the near future). As a result, MTA text databases for the reverse, forward and general databases should be used instead.

To set up text databases:

1. Prepare a text file containing the data.

   This is in the same format that imsimta crdb uses: one entry per line with two fields separated by one or more spaces. The file names are specified by the IMTA_GENERAL_DATA, IMTA_REVERSE_DATA, and IMTA_FORWARD_DATAoptions in imta_tailor), which normally point, respectively, to IMTA_TABLE:general.txt, IMTA_TABLE:reverse.txt, and IMTA_TABLE:forward.txt in msg-svr-base/config/.

   general.txt - general databasereverse.txt - reverse databaseforward.txt - forward database

2. Set the appropriate bit or bits in the USE_TEXT_DATABASES option:

   bit 0 (value 1) - use text file for general databasebit 1 (value 2) - use text file for reverse database bit 2 (value 4) - use text file for forward database

3. Set whatever additional options are needed to enable the desired databases.

   For example, USE_REVERSE_DATABASE, USE_FORWARD_DATABASE, or whatever

4. Run imsimta cnbuild

5. Run imsimta reload

The only case where USE_TEXT_DATABASES is not appropriate is for highly dynamic data. In those cases, you may be better served by writing your own MTA plug-ins rather than by relying on the built-in database support.

If the text database is not appropriate, and you wish to use the crdb (Sleepycat) database support, then it may be possible, by structuring your database usage style and updating process appropriately, to use either imsimta crdb or imsimta db to update the database without recompiling, reloading, or restarting. However, for this to work you either have to be in a situation where you can only add or update existing entries, in which case you can use imsimta crdb. Otherwise, you have to have your data structured as a series of add/delete/change operations. If your data isn't structured this way--and it usually isn't--you're back to replacing the entire database when updating, which in this case, makes text databases preferable.