Architecture of the AXS:One integration
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
.infofile that contains the meta data of the message, the message hash computed by Messaging Server (and stored in the
.infofile's MessageId field), and references to the other files in that set (archive package).
Technical note: The Messaging Server writes the
.infofiles initially as
.tmpfiles, only renaming to
.infoonce all the files referenced by that
.infofile are written and the
.infofile itself is complete. That is, until an archive package is complete, the eventual
.infofile will appear instead as a
.tmpfile. On the AXS:One side, it consumes (and deletes) a
.infofile 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
_mamsg.txt. (Such files will subsequently be consumed by
- 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
imexpireutility has an
archiveaction. Expiration rules configured with the
archiveaction 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
imexpirewill use it, but otherwise will generate a message hash itself; in either case,
imexpirewill 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
imarchiveutility processes the report files generated by AXS:One.
imarchiveshould be scheduled to run periodically to perform this processing task.
imarchiveruns, it renames the
_mamsg.txtfile generated by AXS:One to
pidbefore processing the records in the file. If such processing is successful,
imarchiveremoves the file; otherwise, the file is renamed to