Format of captured message copies

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


"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: <0IH400G04EU3G800@host.domain.com> 
 
an original line of text 

Original message as delivered


Return-path: <user1@domain.com> 
Received: from [10.1.110.115] ([10.1.110.115]) 
 by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit 
 (built Sep  1 2009)) with ESMTP id <0KRH00A3QAO42T10@host.domain.com> 
 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: <0IH400G04EU3G800@host.domain.com> 
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 ldap_domain_attr_capture MTA option or the ldap_capture 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 "capture" 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: <>                                              (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 
 <01NEVLK3B0VK00170V@host.domain.com> 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 <01NEVLJLOOF600156Q@host.domain.com>; 
 Tue, 13 Oct 2009 17:28:11 -0700 (PDT) 
Date: Tue, 13 Oct 2009 17:28:11 -0700 (PDT) 
From: Internet Mail Delivery <postmaster@host.domain.com>    (2)
Subject: Message Capture Copy                                (3)
To: subpoena1-on-user1@domain.com                            (4)
Message-id: <0IH400G08EULG800@ketu.west.sun.com> 
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: <0IH400G04EU3G800@host.domain.com>             (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: <user1@domain.com>                              (12)
Received: from [10.1.110.115] ([10.1.110.115])               (13)
 by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit 
 (built Sep  1 2009)) with ESMTP id <0KRH00A3QAO42T10@host.domain.com>; 
 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: <0IH400G04EU3G800@host.domain.com> 
 
an original line of text 
 
--Boundary_(ID_nChZX4aV2kgbzSzzoDGCvw)-- 

In the captured message copy, note the following items of interest:

  1. 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.)
  2. 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's postmaster address is used, though an override postmaster address may be used if domain-specific postmasters are configured --- see the ldap_domain_attr_report_address MTA option --- or if use of an override postmaster address has been set by the FROM_ACCESS mapping table.)
  3. The Subject: value for captured message copies defaults to the string "Message Capture Copy", or may be set to an alternate string (then used for all DSNs in the relevant language choice) using the SUBJECT option in the return_option.opt file, or may be modified on a per-type-of-DSN basis using the $T flag in the appropriate NOTIFICATION_LANGUAGE mapping table entries.
  4. The message capture copies are sent to the address specified as the value of the attribute named by the ldap_capture or (new in MS 8.0) the ldap_domain_attr_capture MTA option; as for instance in this example the attribute is assumed to have the value subpoena1-on-user1@domain.com. (Or in the case of Sieve "capture" actions, the message capture copies are sent to the address specified in the "capture" action.)
  5. The return_prefix.txt 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 NOTIFICATION_LANGUAGE mapping table is configured to choose an appropriate, language-specific such set of MIME header lines and introductory text.
  6. When the return_prefix.txt file uses the %H 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 return_header.opt file. (New in MS 7.0 update 2, use of language-specific variants of return_header.opt may be configured.) That is, the use of %H substitution in return_prefix.txt causes inclusion of headers, with return_header.opt controlling exactly which headers.
  7. The appropriate, language-specific return_capture.txt file specifies the text added here at the bottom of the first part of the DSN in the case of message capture copies.
  8. The host and channel that are generating the DSN (the captured message copy in this case) are reported.
  9. 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).
  10. 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 useintermediate and suppressfinal channel options alter what is actually reported here), an "Action:" field (which is of course "capture" for capture copies), and a "Status:" field (for capture copies due to ldap_domain_attr_capture or ldap_capture, this field will contain a string along the lines of "Copy requested by capture attribute"; or for capture copies due to Sieve "capture", "Copy requested by capture filter").
  11. The one difference between a captured copy due to use of the ldap_domain_attr_capture or ldap_capture attribute vs. use of a Sieve unadorned "capture" 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".
  12. The envelope From of the original message is reported on the Return-path: header line of the included original message.
  13. 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.
  14. The entire header (all header lines) of the original message is included, as it existed at the point of capture.

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 return_option.opt file, or may be modified on a per-type-of-DSN basis using the $T flag in the appropriate NOTIFICATION_LANGUAGE mapping table entries. The first part of the DSN (the TEXT/PLAIN part), may be localized or site modified via the return_prefix.txt file and the return_capture.txt file corresponding to the relevant language choice, as well as the general return_header.opt file. See DSN language and customization for further details.

When using an ldap_capture or (new in MS 8.0) an ldap_domain_attr_capture 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 ldap_capture and ldap_domain_attr_capture 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 "capture" action. But when using the Sieve "capture" action, two other alternate formats may be generated.

Requesting "capture :message" results in a format such as shown in Captured :message 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'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 "capture :message" copy does not have as much information regarding the original message as would a plain "capture" copy or even a "capture  :journal" 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'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'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.)

Captured :message message copy


Return-path: <postmaster@host.domain.com>                          (1)    
Received: from host.domain.com (host.domain.com [10.1.110.114]) by (2)
 host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit 
 (built Sep  1 2009)) id <01NEVMSAJ6K00015BG@host.domain.com> 
 (original mail from user1@domain.com) 
 for subpoena1-on-user1@domain.com; Tue, 13 Oct 2009 17:28:55 -0700 (PDT) 
Received: from [10.1.110.115] ([10.1.110.115])                     (3)
 by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit 
 (buil
t Sep  1 2009)) with ESMTP id <0KRH00A3QAO42T10@host.domain.com> 
 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: <0IH400G04EU3G800@host.domain.com> 
Original-recipient: rfc822;user2@domain.com 
 
an original line of text 

In the captured :message format message copy, note the following items of interest:

  1. The envelope From address for a "capture :message" copy is the postmaster address; more specifically, it is the owner of whichever system Sieve performed the "capture :message" action, and system Sieves are all owned by the postmaster.
  2. 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 "capture :message" copy is more similar to the effect of a Sieve "redirect" 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.)
  3. 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).
  4. 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.

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

Captured journal 2003 format message copy


Return-path: <>                                              (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 
 <01NEVSAYXRVK0017PR@host.domain.com> 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 <01NEVSA2342U0014CT@host.domain.com>; 
 Tue, 13 Oct 2009 17:28:13 -0700 (PDT) 
Date: Tue, 13 Oct 2009 17:28:13 -0700 (PDT) 
From: Internet Mail Delivery <postmaster@host.domain.com>    (4)
Subject: Message Journal Copy                                (5)
To: subpoena1-on-user1@domain.com                            (6)
Message-id: <0KR2001I49JPZ582@host.domain.com> 
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)
Message-ID: <0IH400G04EU3G800@host.domain.com>               (11)
Recipients: 
 <user2@domain.com>                                          (12)
 
--Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) 
Content-type: message/rfc822                                 (13)
 
Return-path: <user1@domain.com>                              (14)
Received: from [10.1.110.115] ([10.1.110.115])               (15)
 by host.domain.com (Sun Java(tm) System Messaging Server 7.3-11.01 64bit 
 (built Sep  1 2009)) with ESMTP id <0KRH00A3QAO42T10@host.domain.com>; 
 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: <0IH400G04EU3G800@host.domain.com> 
 
an original line of text 
 
--Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)-- 

In the captured journal format message copy, note the following items of interest:

  1. 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.
  2. 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.
  3. This is the Received: header line constructed by the SMTP server during its enqueue of this capture message to the process channel.
  4. The header From: on such a journal message copy is that of the MTA postmaster.
  5. 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.
  6. The header To: shows the capturing address, as directed in the "capture :journal" action or (new in MS 8.0) the value (sans the ;format-journal tag) of an LDAP attribute named by the ldap_capture or ldap_domain_attr_capture or MTA option.
  7. 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.
  8. 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.
  9. This text part contains the journal format's minimal set of envelope information for the captured message (itself contained in the subsequent part).
  10. The envelope From address for the original message is reported on a "Sender:" line.
  11. The Message-id: of the original message is reiterated here.
  12. 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).
  13. 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.
  14. The original envelope From address is reported here in a constructed Return-path: header line.
  15. 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.
  16. From here on, the original message as it existed at time of capture, is duplicated.

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

Captured journal 2007 format message copy


Return-path: <>                                              (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 
 <01NEVSAYXRVK0017PR@host.domain.com> 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 <01NEVSA2342U0014CT@host.domain.com>; 
 Wed, 28 Jul 2010 17:28:13 -0700 (PDT) 
Date: Wed, 28 Jul 2010 17:28:13 -0700 (PDT) 
From: Internet Mail Delivery <postmaster@host.domain.com>    (4)
Subject: Message Journal Copy                                (5)
To: subpoena1-on-user1@domain.com                            (6)
Message-id: <0KR2001I49JPZ582@host.domain.com> 
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: <0IH400G04EU3G800@host.domain.com>               (11)
To: <user2@domain.com>                                       (12)
 
--Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg) 
Content-type: message/rfc822                                 (13)
 
Return-path: <user1@domain.com>                              (14)
Received: from [10.1.110.115] ([10.1.110.115])               (15)
 by host.domain.com (Sun Java(tm) System Messaging Server 7.5-11.01 64bit 
 (built Jul 23 2010)) with ESMTP id <0KRH00A3QAO42T10@host.domain.com>; 
 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: <0IH400G04EU3G800@host.domain.com> 
 
an original line of text 
 
--Boundary_(ID_xWvHuuTuAMSgGf6g0CDWjg)-- 

In the captured journal format message copy, note the following items of interest:

  1. 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.
  2. 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.
  3. This is the Received: header line constructed by the SMTP server during its enqueue of this capture message to the process channel.
  4. 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 journal_format is set, then the From: field value will be set to that of the original message.
  5. 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 journal_format is set (in which case the Subject: field value is set to that of the original message).
  6. The header To: normally shows the capturing address, as directed in the "capture :journal" action. New in MS 7.0.5, if bit 1 (value 2) of the MTA option journal_format is set, then the To: field value will be set to that of the original message.
  7. 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 journal_format is set, then an X-MS-Exchange-Organization-Journal-Report: header line is generated rather than an X-MS-Journal-Report: header line.
  8. 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.
  9. This text part contains the journal format's minimal set of envelope information for the captured message (itself contained in the subsequent part).
  10. 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.)
  11. The Message-id: of the original message is reiterated here.
  12. 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 journal_format 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 addrtypescan 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 addrtypescan channel option has been applied, then envelope recipient addresses may be denoted with "To:" (if exactly matching a header To: or Resent-To: value), or denoted with "Cc:" or "Bcc:" similarly, or denoted with simply "Recipient:" if no such exact string match exists; "Recipient:" is also what is used whenever addrtypescan) was not applied. Recipient addresses may be further elaborated with "Forwarded:" or "Expanded:" 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.

  13. 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.
  14. The original envelope From address is reported here in a constructed Return-path: header line.
  15. 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.
  16. From here on, the original message as it existed at time of capture, is duplicated.


See also: