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&#x27;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   file that contains the meta    data of the message, the message hash computed by Messaging Server (and    stored in the   file&#x27;s MessageId field), and    references to the other files in that set (archive package).

Technical note: The Messaging Server writes the  files initially as    files, only renaming to   once all  the files referenced by that   file are written and  the   file itself is complete. That is, until an archive package is complete, the eventual   file will  appear instead as a   file. On the AXS:One side, it consumes (and deletes) a   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  . (Such files will subsequently be consumed by  .)



 The MTA&#x27;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&#x27;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&#x27;s  utility has an      action. Expiration rules configured   with the      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      will use    it, but otherwise will generate a message hash itself; in either case,      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&#x27;s  utility processes the    report files generated by AXS:One. should be   scheduled    to run periodically to perform this processing task.

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





See also:
 * Message identifier generation
 * store.expirerule file rulesets
 * Scheduler task options
 * AXS:One archive integration