MESSAGE-SAVE-COPY mapping table

The  mapping table provides a way to tell the  MTA to  copy (rename) message files from its disk queue area when dequeuing  messages. The resulting files are in the MTA&#x27;s disk queue area (proprietary) format. When copied (renamed) to some area outside the MTA&#x27;s normal disk queue area, these copies of the MTA&#x27;s message files  are no longer subject to normal processing by the MTA. But if subsequently renamed back into the MTA&#x27;s disk queue area, the message  files are perfectly suited to being "picked up" by the MTA,  and re-sent just as the original message files were sent.

The original motivation for this facility was as a means to capture copies of messages outbound from the MTA to be retained (for some  period) for purposes of potential future "message replay",  that is, it was intended to be used to resend messages in case of  disaster on the original receiving host(s). (The new-in-MS-8.0  channel option provides a different facility, with different trade-offs,  that can also be suitable for certain "message replay" purposes.) The   facility can  potentially be used, however, for other purposes such as monitoring  (capturing) of messages sent by particular users, or as a way to obtain  message copies for long-term archiving purposes.

When using this facility for purposes of monitoring particular users&#x27; e-mail messages, keep in mind that while capturing of messages sent  from a particular user is straightforward enough (the    mapping table probes include the envelope From  address as part of the probe field), the capturing of messages sent  to a particular user is less straightforward with this  facility, as it normally distinguishes only between classes of  destination addresses---that is, it distinguishes on a destination  channel basis (as the   mapping table probes  include  the destination channel, but not the envelope To recipient(s)). Thus if it is desired to use this facility to capture specifically those  messages to a particular user or users, it may be necessary to either  capture additional messages (to other recipients) as well and then in  some site-supplied subsequent processing discard the undesired  messages, or else to perform some additional, more complex,  configuration of the MTA to allow the    mapping table  to distinguish which messages are to the recipient(s) in question.

When using this facility to obtain message copies that will then be further processed, e.g., delivered into an archiving system,  note that the copies created are in MTA message file format. All access to such message files should be done via the MTA SDK. (Essentially, a channel program should be written to process the messages.) Accessing  the message files only through the MTA SDK insulates applications from  potential future changes in the MTA&#x27;s message file structure  (particularly, changes and additions to the message envelope portion of  the message file).

The choice of when the  mapping table should be  applied -- for which destination channel(s), and in a multi-host e-mail  environment, on which hosts---should be carefully considered in  relation to the fundamental goals of the message capture. And typically some thought needs to be given to issues of message "split  up" -- the cases where a multi-recipient message may bifurcate  into separate "copies" due to different recipients needing  different types of handling -- in relation to the message capture  goals. If the goal is simply to capture "all messages going out a particular channel" (the case for which this facility was  designed), achieving that goal is simple. But otherwise, other questions arise. Is the goal to capture each such message copy? Will there be a desire to "correlate" or "consolidate"  the cases where separate eventual message copies all correspond to a  single, originally submitted message? In a multi-host environment, is it desired to capture merely those messages passing through a  particular host? Or do messages potentially need to be captured on multiple hosts and if so, does there need to be some  "correlation" or "consolidation" of the message  copies captured on different hosts (some of which copies may consist of  the "same" message, at a different point in its processing  life-cycle)? As regards message "split-up", a most basic example would be the case of a multi-recipient message where the  recipients are destined out different channels. But there are also many other sorts of message processing that imply separate handling via  separate message files, such as local recipients with different  conversion tags,  or mailing list recipients vs. directly addressed recipients, etc. Even on a single system, the  potential use of any "intermediate" channels such as the  conversion or  reprocess channels should be considered in  relation to  timing of the   operation. And when operating in a multi-host environment, the timing and message bifurcation issues tend  to become more complex.

See also:
 * clonehosts Option
 * message_save_copy_flags MTA Option
 * MESSAGE-SAVE-COPY mapping table format and examples
 * Message replay of captured message copies
 * Conversion channel
 * Process and reprocess channels
 * Conversion tags
 * Message capture