Format of captured message copies

"Captured" message copies by default are in the form of Delivery Status Notifications  (see RFC 1892). So for instance, if an original message has the form shown in  Original message to be captured,  as submitted at the point when  the MTA applies capture (for instance capture performed by the SMTP  server when the message is first submitted)---and where, for  comparison, that original message by the time it is delivered to a user  mailbox might have a form as shown in  Original message as delivered:

 Original message to be captured, as submitted Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; an original line of text

 Original message as delivered Return-path: &#x3c;user1@domain.com&#x3e; Received: from &#x5b;10.1.110.115&#x5d; (&#x5b;10.1.110.115&#x5d;) by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit  (built Sep  1 2009)) with ESMTP id &#x3c;0KRH00A3QAO42T10@host.domain.com&#x3e; for user2@domain.com; Tue, 13 Oct 2009 17:28:52 -0700 (PDT) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; Original-recipient: rfc822;user2@domain.com an original line of text then a captured message copy (the copy generated and sent to the value of an LDAP attribute named by  the   MTA option or the   MTA option)  would have the  form shown in Captured message copy (default DSN format). Similarly, a captured message copy generated and sent to the address named in an unadorned  " " Sieve  action would have almost exactly  that same form, with only a minor text difference as discussed at   (11).

 Captured message copy (default DSN format) Return-path: &#x3c;&#x3e;                                             (1) Received: from process-daemon.host.domain.com by host.domain.com (Sun Java(tm)  System Messaging Server 7.3-11.01 64bit (built Sep  1 2009)) id   &#x3c;01NEVLK3B0VK00170V@host.domain.com&#x3e; for subpoena1-on-user1@domain.com; Tue, 13 Oct 2009 17:28:14 -0700 (PDT) Received: from host.domain.com (Sun Java(tm) System Messaging Server  7.3-11.01 64bit (built Sep  1 2009)) id &#x3c;01NEVLJLOOF600156Q@host.domain.com&#x3e;; Tue, 13 Oct 2009 17:28:11 -0700 (PDT) Date: Tue, 13 Oct 2009 17:28:11 -0700 (PDT) From: Internet Mail Delivery &#x3c;postmaster@host.domain.com&#x3e;   (2) Subject: Message Capture Copy                               (3) To: subpoena1-on-user1@domain.com                           (4) Message-id: &#x3c;0IH400G08EULG800@ketu.west.sun.com&#x3e; MIME-version: 1.0 Original-recipient: rfc822;subpoena1-on-user1@domain.com Content-type: multipart/report; report-type=delivery-status; boundary="Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw)" --Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw) Content-type: text/plain; charset=us-ascii                  (5) Content-language: en-US This report relates to a message you sent with the following header fields: Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e;            (6) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT) From: user1@domain.com To: user2@domain.com Subject: test message Attached message captured in accordance with site policy. (7) --Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw) Content-type: message/delivery-status Reporting-MTA: dns;host.domain.com (tcp_intranet-daemon)    (8) Arrival-date: Tue, 13 Oct 2009 17:28:02 -0700 (PDT)         (9) Original-recipient: rfc822;user2@domain.com                 (10) Final-recipient: rfc822;user2@domain.com Action: capture Status: 2.0.0 (Copy requested by capture attribute)         (11) --Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw) Content-type: message/rfc822 Return-path: &#x3c;user1@domain.com&#x3e;                             (12) Received: from &#x5b;10.1.110.115&#x5d; (&#x5b;10.1.110.115&#x5d;)              (13) by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit  (built Sep  1 2009)) with ESMTP id &#x3c;0KRH00A3QAO42T10@host.domain.com&#x3e;; Tue, 13 Oct 2009 17:28:11 -0700 (PDT) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT)                 (14) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; an original line of text --Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw)-- In the captured message copy, note the following items of interest:



  As with any DSN, note that the envelope From   address on this DSN is empty. (Note that the addition of a Return-path:   header line only occurs at final message delivery time; if looking at    the capture message copy earlier, such as while it is transitting the    MTA, this header line would not be expected to be present.) 

  Captured message copies are encapsulated,   with the new, encapsulating message having the form of a notification    message: an empty envelope From and a From: header value set to the    postmaster address. (By default, the host&#x27;s   postmaster address is used,    though an override postmaster address may be used if domain-specific    postmasters are configured --- see the          MTA  option --- or if use of an    override postmaster address has been set by the       mapping table.) 

  The Subject: value for captured message   copies defaults to the string " ", or may be set to an alternate string (then used for    all DSNs in the relevant language choice) using the    SUBJECT option in    the   file, or may be modified on a    per-type-of-DSN basis using the   flag in the appropriate         mapping table entries. 

  The message capture copies are sent to the   address specified as the value of the attribute named by the        or (new in MS 8.0) the      MTA option; as for instance in this example the attribute    is assumed to have the value. (Or in the case of   Sieve    " " actions, the message capture copies    are sent to the address specified in the    " " action.) </li>

 <span id='call_083'> The       file is    used to construct the first part of DSN messages: specifically, the    MIME header lines, plus (typically, and in particular in this example)    the introductory text line and insertion of a sample of the original    message headers. Normally, the        mapping table is    configured to choose an appropriate, language-specific such set of MIME    header lines and introductory text. </li>

 <span id='call_084'> When the       file   uses the   substitution, exactly which header lines from    the original message that will cause to be included in this first part    normally is controlled, for all DSNs of all types in all languages, by    the        file. (New in MS 7.0 update 2, use   of language-specific variants of   may be    configured.) That is, the use of   substitution in      causes inclusion of headers, with      controlling exactly which headers. </li>

 <span id='call_085'> The appropriate, language-specific       file specifies the text added here at    the bottom of the first part of the DSN in the case of message capture    copies. </li>

 <span id='call_086'> The host and channel that are generating the   DSN (the captured message copy in this case) are reported. </li>

 <span id='call_087'> As of MS 7.0, the arrival date of when   the message "arrived" at the reporting MTA is reported on an    "Arrival-date:" line. Note that as this represents the time   when the MTA began processing this message, it will tend to be    a time slightly prior to the time of the Received: header line that the    MTA added on this "capture" message copy (though this time is    of course after the time at which the original message was composed). </li>

 <span id='call_088'> For each current recipient of the message, a   set of fields is output, reporting on that recipient. Normally this set   consists of an "Original-recipient:" field, a    "Final-recipient:" field (note that the      and      channel options   alter what is actually reported here), an    "Action:" field (which is of course    " " for capture copies), and a    "Status:" field (for capture copies due to       or   , this field will   contain a string along the lines of     "Copy requested by capture attribute"; or for capture copies    due to Sieve " ", "Copy requested by    capture filter"). </li>

 <span id='call_089'> The one difference between a captured copy   due to use of the       or     attribute    vs. use of a Sieve   unadorned " " action is whether the text    reported on the Status: line says "Copy requested by capture    attribute" (or one of the new in MS 8.0 variants corresponding to tagged LDAP attribute value "Copy requested by journal attribute", "Copy requested by capture header attribute", "Copy requested by journal header attribute")   vs. "Copy requested by capture    filter". </li>

 <span id='call_090'> The envelope From of the original message is   reported on the Return-path: header line of the included original    message. </li>

 <span id='call_091'> For the captured message copy, a Received:   header line closely corresponding to the Received: header line that was    constructed for the original message during the processing at the time    that the original message was captured, is constructed and reported    here. </li>

 <span id='call_092'> The entire header (all header lines) of the   original message is included, as it existed at the point of capture. </li>

</ol>

Note that as usual with DSNs, some customization of the text intended to be human-readable is possible. The text value on the Subject: header line may be modified (for all DSNs in the relevant language choice) via  the    SUBJECT option in    the   file, or may be modified on a    per-type-of-DSN basis using the   flag in the appropriate         mapping table entries. The first part of the DSN (the TEXT/PLAIN part), may be localized or site modified via the     file and the    file  corresponding to the relevant  language choice, as well as the general    file. See DSN language and customization for further details.

When using an  or (new in MS 8.0) an    named LDAP attribute, the regular, DSN form  of captured message copy, as shown in  Captured message copy (default DSN format)  (or with the  slight variations configurable via DSN configuration as discussed  there) is  (prior to MS 8.0) always generated. (New in MS 8.0, the LDAP attributes named by the   and    MTA options supported tagged values, where the tags select the format to be generated.  So as of MS 8.0, LDAP attribute triggered capture can also cause generation of "journal" format, or of modified DSN or "journal" format containing only headers of the original message -- which may be useful for administrative monitoring that preserves message content privacy.)  That DSN format is also (essentially) the format  generated by default when using the Sieve  " " action. But when using the Sieve " " action, two other alternate formats  may be generated.

Requesting " " results in a format such as shown in  Captured   message  copy, where the capture copy is not  much changed from the original message copy, other than the original  envelope From address being overriden for the capture copy to be that  of the relevant system Sieve&#x27;s "owner" (normally the  postmaster address), and  differences in Received: header line(s)  corresponding to the new routing of the capture message copy. Although such a " " copy does not have as  much information regarding the original message as would a plain  " " copy or even a " " copy (as discussed in  Captured journal 2003 format message copy)  ---  specifically, this form of capture does not have  fields in which to record the original message copy&#x27;s envelope From and  envelope To values --- for some purposes it may provide sufficient  information and its "simple" structure may be convenient. However, because the fact that this is a capture message copy is not called out obviously in the capture message copy&#x27;s header,  the  recipient of such capture copies will need to be alert to the  reason  why he or she has received the capture copy! Hence, typically the mailbox receiving such capture copies should be either: (a) a special mailbox  dedicated to receiving such capture copies, or (b) the mailbox of a  sophisticated e-mail user who knows to expect capture copies, and knows  to look carefully at all messages received so as to detect which  messages are being received due to capturing and handle such received  messages appropriately. (For instance, if a dedicated mailbox is not available, consider directing capture copies to a distinguished  subaddress of the mailbox, combined with a  Sieve filter that detects  the presence of the subaddress to cause special handling, such as  delivery into a special folder.)

<span id='figure_capture_message'> Captured  message copy Return-path: &#x3c;postmaster@host.domain.com&#x3e;                         (1) Received: from host.domain.com (host.domain.com &#x5b;10.1.110.114&#x5d;) by (2) host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit  (built Sep  1 2009)) id &#x3c;01NEVMSAJ6K00015BG@host.domain.com&#x3e; (original mail from user1@domain.com) for subpoena1-on-user1@domain.com; Tue, 13 Oct 2009 17:28:55 -0700 (PDT) Received: from &#x5b;10.1.110.115&#x5d; (&#x5b;10.1.110.115&#x5d;)                    (3) by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit  (buil t Sep 1 2009)) with ESMTP id &#x3c;0KRH00A3QAO42T10@host.domain.com&#x3e; for subpoena1-on-user1@domain.com; Tue, 13 Oct 2009 17:28:52 -0700 (PDT) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT)                       (4) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; Original-recipient: rfc822;user2@domain.com an original line of text In the captured  format message copy, note the  following items of interest:

<ol>

 <span id='call_093'> The envelope From address for a   " " copy is the    postmaster address;    more specifically, it is the owner   of whichever system Sieve    performed the " " action, and    system Sieves are all owned by the postmaster. </li>

 <span id='call_094'> This is the Received: header line constructed   during the enqueue from the reprocess channel   to the delivery channel. (Unlike the other capture formats, which are   notification messages    processed through the process channel,    the processing of a    " " copy is more similar to the    effect of a    Sieve " "   action and in    particular,   (prior to MS 8.0)   is handled through the    reprocess channel.  As of MS 8.0, the process channel, rather than the reprocess channel,    handles these messages too.) </li>

 <span id='call_095'> This is the Received: header line constructed   by the SMTP server enqueuing this capture message copy to the reprocess    channel. Note that this Received: header line in the capture message   copy is very similar to the Received: header that the SMTP server added    to the original message; the difference is in the respective    "for recipient-address" clauses,    as the capture message copy    shows the recipient address for this capture message copy (if there is    only one capture message recipient). </li>

 <span id='call_096'> From here on, the copy consists of the   original message (all its original header lines); in particular, the    header From: is still that of the original message. Note that when   capturing a message that had been relayed, the captured message copy    would also contain more Received: header lines than shown here, if the    original message (as in a relayed message) itself contained Received:    header lines; but this example corresponds to an original message whose    initial submission was to this MTA, with the capture being triggered    during the processing of that initial submission. </li>

</ol>

Alternatively, again with the original message shown in Original message to be captured, as submitted, a basic (2003 format) " "  (or an LDAP attribute triggered capture due to an LDAP attribute named by    or   having a value tagged by  ) message  copy would have the form shown in  Captured journal 2003 format message copy:

<span id='figure_capture_journal'> Captured journal 2003 format message copy Return-path: &#x3c;&#x3e;                                             (1) Received: from process-daemon.host.domain.com by host.domain.com (Sun Java(tm) (2) System Messaging Server 7.3-11.01 64bit (built Sep  1 2009)) id   &#x3c;01NEVSAYXRVK0017PR@host.domain.com&#x3e; for subpoena1-on-user1@domain.com; Tue, 13 Oct 2009 17:28:25 -0700 (PDT) Received: from host.domain.com (Sun Java(tm) System Messaging Server (3)  7.3-11.01 64bit (built Sep  1 2009)) id &#x3c;01NEVSA2342U0014CT@host.domain.com&#x3e;; Tue, 13 Oct 2009 17:28:13 -0700 (PDT) Date: Tue, 13 Oct 2009 17:28:13 -0700 (PDT) From: Internet Mail Delivery &#x3c;postmaster@host.domain.com&#x3e;   (4) Subject: Message Journal Copy                               (5) To: subpoena1-on-user1@domain.com                           (6) Message-id: &#x3c;0KR2001I49JPZ582@host.domain.com&#x3e; MIME-version: 1.0 Original-recipient: rfc822;subpoena1-on-user1@domain.com X-MS-Journal-Report:                                        (7) Content-type: multipart/mixed; boundary="Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)" (8) --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) Content-type: text/plain                                    (9) Sender: &#x3c;user1@domain.com&#x3e;                                  (10) Message-ID: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e;              (11) Recipients: &#x3c;user2@domain.com&#x3e;                                         (12) --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) Content-type: message/rfc822                                (13) Return-path: &#x3c;user1@domain.com&#x3e;                             (14) Received: from &#x5b;10.1.110.115&#x5d; (&#x5b;10.1.110.115&#x5d;)              (15) by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit  (built Sep  1 2009)) with ESMTP id &#x3c;0KRH00A3QAO42T10@host.domain.com&#x3e;; Tue, 13 Oct 2009 17:28:11 -0700 (PDT) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT)                 (16) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; an original line of text --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)-- In the captured journal format message copy, note the following items of interest:

<ol>

 <span id='call_097'> The journal format is a   notification message:    it has an empty envelope From, as reported here on the Return-path:    header line for this journal capture copy. </li>

 <span id='call_098'> This is the Received: header line constructed   during the enqueue from the process channel   to the delivery channel. Note that journal format message copies, being constructed as   notification messages, are generated via the process channel. </li>

<li> <span id='call_099'> This is the Received: header line constructed   by the SMTP server during its enqueue of this capture message to the    process channel. </li>

<li> <span id='call_100'> The header From: on such a journal message   copy is that of the MTA postmaster. </li>

<li> <span id='call_101'> The Subject: header line says "Message   Journal Copy" for such copies -- unless use of different Subject:    text has been configured as discussed in     DSN language and customization. </li>

<li> <span id='call_102'> The header To: shows the capturing address,   as directed in the " "   action  or (new in MS 8.0) the value (sans the      tag)  of an LDAP attribute named by the      or       or MTA option. </li>

<li> <span id='call_103'>   New in   MS 7.0u4,   a X-MS-Journal-Report:    header line is generated, as some third-party archive software appears    to require such a header line. </li>

<li> <span id='call_104'> Note that the journal format consists, at   the outermost MIME level, of a multipart/mixed part; this is in    contrast to the default, DSN format for captured messages, which,    making use of the standard notification message format, consists of a    multipart/report part at the outermost MIME level. </li>

<li> <span id='call_105'> This text part contains the journal format&#x27;s   minimal set of envelope information for the captured message (itself    contained in the subsequent part). </li>

<li> <span id='call_106'> The envelope From address for the original   message is reported on a "Sender:" line. </li>

<li> <span id='call_107'> The Message-id: of the original message is   reiterated here. </li>

<li> <span id='call_108'> The list of envelope To recipients are   reported, one envelope To recipient per line. As of MS 7.0u3, any   source routes on the envelope To recipient address or addresses are    removed. As of MS 7.0.5,  it is the so-called "intermediate address"  rather than the "final address" that is reported; this is  especially notable for local Message Store recipients. This example corresponds to an original message having only one recipient (or more  precisely, an original message having only one recipient at time of  capture). </li>

<li> <span id='call_109'> This message part contains the original   message, essentially as it existed at time of capture, but with the    addition of a Return-path: header line, plus a constructed Received:    header line contemporaneous with capture processing. </li>

<li> <span id='call_110'> The original envelope From address is   reported here in a constructed Return-path: header line. </li>

<li> <span id='call_111'> A Received: header line is present   effectively corresponding to the Received: header line constructed for    the original message while capture processing was occurring, though    this journal capture copy Received: header line contains no "for    ..." clause. </li>

<li> <span id='call_112'> From here on, the original message as it   existed at time of capture, is duplicated. </li>

</ol>

Alternatively, again with the same original message, a journal 2007 format message as generated due to a " " action when the  (new in  MS 7.0.5) MTA option    has bit 0 (value 1)  set and when the     channel option has been set on all relevant channels, would have the  form shown in  Captured journal 2007 format message  copy:

<span id='figure_capture_journal2007'> Captured journal 2007 format message copy Return-path: &#x3c;&#x3e;                                             (1) Received: from process-daemon.host.domain.com by host.domain.com (Sun Java(tm) (2) System Messaging Server 7.5-11.01 64bit (built Jul 23 2010)) id   &#x3c;01NEVSAYXRVK0017PR@host.domain.com&#x3e; for subpoena1-on-user1@domain.com; Wed, 28 Jul 2010 17:28:25 -0700 (PDT) Received: from host.domain.com (Sun Java(tm) System Messaging Server (3)  7.5-11.01 64bit (built Jul 23 2010)) id &#x3c;01NEVSA2342U0014CT@host.domain.com&#x3e;; Wed, 28 Jul 2010 17:28:13 -0700 (PDT) Date: Wed, 28 Jul 2010 17:28:13 -0700 (PDT) From: Internet Mail Delivery &#x3c;postmaster@host.domain.com&#x3e;   (4) Subject: Message Journal Copy                               (5) To: subpoena1-on-user1@domain.com                           (6) Message-id: &#x3c;0KR2001I49JPZ582@host.domain.com&#x3e; MIME-version: 1.0 Original-recipient: rfc822;subpoena1-on-user1@domain.com X-MS-Journal-Report:                                        (7) Content-type: multipart/mixed; boundary="Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)" (8) --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) Content-type: text/plain                                    (9) Sender: user1@domain.com                                    (10) Subject: test message Message-ID: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e;              (11) To: &#x3c;user2@domain.com&#x3e;                                      (12) --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) Content-type: message/rfc822                                (13) Return-path: &#x3c;user1@domain.com&#x3e;                             (14) Received: from &#x5b;10.1.110.115&#x5d; (&#x5b;10.1.110.115&#x5d;)              (15) by host.domain.com (Sun Java(tm) System Messaging Server 7.5-11.01 64bit  (built Jul 23 2010)) with ESMTP id &#x3c;0KRH00A3QAO42T10@host.domain.com&#x3e;; Wed, 28 Jul 2010 17:28:11 -0700 (PDT) Date: Tue, 13 Oct 2009 17:27:03 -0700 (PDT)                 (16) Subject: test message From: user1@domain.com To: user2@domain.com Message-id: &#x3c;0IH400G04EU3G800@host.domain.com&#x3e; an original line of text --Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)-- In the captured journal format message copy, note the following items of interest:

<ol>

<li> <span id='call_113'> The journal format is a   notification message:    it has an empty envelope From, as reported here on the    Return-path: header line for this journal capture copy. </li>

<li> <span id='call_114'> This is the Received: header line   constructed during the enqueue from the    process channel to the delivery    channel. Note that journal format message copies, being constructed as   notification messages, are generated via the process channel. </li>

<li> <span id='call_115'> This is the Received: header line   constructed by the SMTP server during its enqueue of this capture    message to the process channel. </li>

<li> <span id='call_116'> The header From: on such a journal message   copy is, by default, that of the MTA    postmaster. New in MS 7.0.5, if bit    1 (value 2) of the MTA option      is set,    then the From:    field value will be set to that of the original message. </li>

<li> <span id='call_117'> The Subject: header line normally says   "Message Journal Copy" for such copies -- unless use of    different Subject: text has been configured as discussed in    DSN language and customization,    or (new in  MS 7.0.5) unless bit 1 (value 2) of    the MTA    option   is set    (in which case the Subject: field value is    set to that of the original message). </li>

<li> <span id='call_118'> The header To: normally shows the capturing   address, as directed in the " "    action. New in MS 7.0.5,    if bit 1 (value 2) of the MTA option      is set,    then the To: field value will be set to that of    the original message. </li>

<li> <span id='call_119'>   New in MS 7.0u4, a X-MS-Journal-Report:    header line is generated, as some third-party archive software appears    to require such a header line. New in MS 7.0.5,   if bit 2 (value 4) of    the MTA option      is set, then an    X-MS-Exchange-Organization-Journal-Report: header line is generated    rather than an X-MS-Journal-Report: header line. </li>

<li> <span id='call_120'> Note that the journal format consists, at   the outermost MIME level, of a multipart/mixed part; this is in    contrast to the default, DSN format for captured messages, which,    making use of the standard notification message format, consists of a    multipart/report part at the outermost MIME level. </li>

<li> <span id='call_121'> This text part contains the journal format&#x27;s   minimal set of envelope information for the captured message (itself    contained in the subsequent part). </li>

<li> <span id='call_122'> The envelope From address for the original   message is reported on a "Sender:" line. (Note that unlike   2003 format, the envelope From is not enclosed in angle brackets.) </li>

<li> <span id='call_123'> The Message-id: of the original message is   reiterated here. </li>

<li>

<span id='call_124'> The list of envelope To recipients are   reported, one envelope To recipient per line. As of MS 7.0u3, any   source routes on the envelope To recipient address or addresses are    removed. As of MS 7.0.5,  it is the so-called "intermediate address"  rather than the "final address" that is reported; this is  especially notable for local Message Store recipients. With bit 0 (value 1) of the MTA option    set,  as well as optionally  also bit 3 (value 8), what exactly will be noted on each envelope To  recipient line will depend upon whether the    channel option has  applied, and if so, on whether envelope To recipient address strings  exactly match recipient header values. This example corresponds to an original message having only one recipient (or more  precisely, an original message having only one recipient at time of  capture), and where that envelope To recipient string is  exactly the same as a value on the To: header line. When the   channel option has been applied, then envelope  recipient addresses may be denoted with " "  (if exactly matching a header To: or Resent-To: value), or denoted with  " " or " "  similarly, or denoted with simply " "  if no such exact string match exists;  " " is also what is used whenever   ) was not applied. Recipient addresses may be  further elaborated with " " or  " " labelling, e.g.,  To: active-address, Forwarded: original-address in those cases where the MTA can detect that forwarding or list  expansion, respectively, has occurred.

</li>

<li> <span id='call_125'> This message part contains the original   message, essentially as it existed at time of capture, but with the    addition of a Return-path: header line, plus a constructed Received:    header line contemporaneous with capture processing. </li>

<li> <span id='call_126'> The original envelope From address is   reported here in a constructed Return-path: header line. </li>

<li> <span id='call_127'> A Received: header line is present   effectively corresponding to the Received: header line constructed for    the original message while capture processing was occurring, though    this journal capture copy Received: header line contains no "for    ..." clause. </li>

<li> <span id='call_128'> From here on, the original message as it   existed at time of capture, is duplicated. </li>

</ol>

See also:
 * Notification message format
 * ldap_domain_attr_capture MTA Option
 * ldap_capture MTA Option
 * Sieve capture extension
 * Postmaster addresses
 * ldap_domain_attr_report_address MTA Option
 * FROM_ACCESS mapping table
 * The optional return_option.opt file
 * DSN language and customization
 * The required full set of DSN type-specific return_...txt files
 * useintermediate Option
 * suppressfinal Option
 * Sieve subaddress extension
 * journal_format MTA Option
 * addrtypescan Option
 * Postmaster addresses
 * Message capture