Architecture of the AXS:One integration

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

The Messaging Server integration with AXS:One has the following components:

  • The MTA and Message Store can compute a message hash to be used as a unique identifier of the message for AXS:One's purposes.
  • Data transfer between Messaging Server (either or both of the MTA and the Message Store) and AXS:One is via configuration-specific file drop directories.

    In one such file drop directory, the MTA and Message Store can deposit message copy files: for each message, AXS:One wants an "archive package" consisting of the message main body, any attachment files, and a .info file that contains the meta data of the message, the message hash computed by Messaging Server (and stored in the .info file's MessageId field), and references to the other files in that set (archive package).

    Technical note: The Messaging Server writes the .info files initially as .tmp files, only renaming to .info once all the files referenced by that .info file are written and the .info file itself is complete. That is, until an archive package is complete, the eventual .info file will appear instead as a .tmp file. On the AXS:One side, it consumes (and deletes) a .info file and all the files it references as part of its processing.

    In another file drop directory, AXS:One deposits report files to inform Message Server after it has archived messages.

    Technical note: AXS:One writes a single line record per message to the report file. When writing, AXS:One writes to a tmp file; when the file is completed, it is renamed to timestamp_mamsg.txt. (Such files will subsequently be consumed by imarchive.)

  • The MTA's general "spam filter" plug-in approach can be used to call an AXS:One specific plug-in module. During message enqueues, the MTA can call the AXS:One integration plug-in which generates message copy files (an "archive package") suitable for AXS:One consumption and deposits those message copy files in the integration file drop directory. All the MTA's usual configuration options regarding which messages to copy for archiving are thereby available. As this archiving is occurring while messages are transitting the MTA, it is usually a part of compliance archiving.
  • The Message Store's imexpire utility has an archive action. Expiration rules configured with the archive action control which messages are moved to the archive. This is primarily used for operational archiving: for instance, moving older (or larger) messages off to the archive. If the message already has a message hash identifier for the message , then imexpire will use it, but otherwise will generate a message hash itself; in either case, imexpire will both include the message hash in the archive package it generates for AXS:One, and insert the message hash into the msghash database.

  • The Message Store's imarchive utility processes the report files generated by AXS:One. imarchive should be scheduled to run periodically to perform this processing task.

    Technical noteWhen imarchive runs, it renames the timestamp_mamsg.txt file generated by AXS:One to before processing the records in the file. If such processing is successful, imarchive removes the file; otherwise, the file is renamed to timestamp_mamsg.err.

See also: