Message identifier generation

When doing archiving, whether with the AXS:One archiving module or via some other mechanism, it is typically useful or even required to  "identify" messages via some identifier. The MTA has the ability to generate an identifying "hash" for messages  passing through it, based on configurable selection of message  features. It is also (at least typically) necessary to uniquely identify the recipient(s) of the archived message copies---and in some  cases, using the recipient&#x27;s (canonical) e-mail address may not be the  preferred choice. The MTA has an option to control the generation of message recipient identifiers. These options will be discussed below.

Messages undergo more-or-less constant change during their traverse from initial submission to eventual final delivery: Received: header  lines are added at each "hop"; mailing lists get expanded  changing the set of recipients for a message; for a multi-recipient  message, the message may need to get "split up" into separate  copies for separate types of recipients; individual addresses undergo  routing and esthetic transformations; message contents may be modified  as for example addition of header lines indicating spam/virus filtering  or content encoding changes or character set conversions, or addition  of "disclaimer" text, etc. So  "identifying" a message is not a straightforward question:  one  has to ask which portions of a message "matter" as far as  the identification is concerned, vs. which sorts of "changes" should be ignored. By default, the MTA generates a hash over the following message fields (or a different set may be  selected using the    MTA option):

 Message-id: 

 From: 

 To: 

 Cc: 

 Bcc: 

 Resent-message-id: 

 Resent-From: 

 Resent-To: 

 Resent-Cc: </li>

 Resent-Bcc: </li>

 Subject: </li>

 Content-id: </li>

 Content-type: </li>

 Content-description: </li>

</ul>

(Note that the Content-type: and Content-description: header are those from the top or outermost MIME level of the message.)

Keep in mind that the choice of when (which channel(s)) to generate a  message hash will affect which version(s) of a message are archived. A typical configuration, especially for "operational" mode,  might be to set     on channels delivering  to the Message Store, such as    and    channels,  with    (the default)  on all other channels (especially   ). Such a configuration would result in separate message hashes for each message copy separate at the time of enqueue to  the final delivery channel. Or in other cases, where it is desired to archive only an "earlier" copy of messages, possibly a copy  from before certain later message bifurcations have occurred, then  another potentially useful configuration (especially in  "compliance" mode) might be to set    "earlier", such as on any  (known to be used) "intermediate" channels and on channels  delivering to other internal hosts such as. Any final delivery channels such as    or   will still need either    set  (if such messages are guaranteed to  have already passed through a channel that did hash generation---as in  the case of messages that have already passed through a "front  end" MTA) or   if it is possible  for a message to get to the channel without a previously generated hash. And a channel delivering externally (such as )  should again be  set.

The   MTA option may be used to configure how unique recipient  identifiers will be generated for purposes of archiving.

See also:
 * message_hash_fields MTA Option
 * generatemessagehash Option
 * deletemessagehash Option
 * keepmessagehash Option
 * ims-ms channels
 * LMTP client TCPIP channels
 * Typical TCPIP channels and servers
 * unique_id_template MTA Option
 * Archiving messages