Envelope Journaling


Modern mail servers typically support envelope journaling in some form or fashion. The task of a mail server's journaling function (such as Microsoft Exchange Envelope Journaling) is to ensure that an archive server retains an exact copy of all messages flowing through the mail server. In doing so, the mail server forwards journal messages directly to the archive server via a protocol such as SMTP.


The emails outputted by the mail server's journaling function are encapsulated in a message envelope (i.e. a journal envelope). The journal envelope is an email in-of-itself (i.e. an RFC2822 wrapper) with the original email presented as an attachment. The body of the journal envelope message contains metadata pertaining to the original message. The purpose of the envelope is to provide additional meta information about the message such as origin, destination, timestamp, recipients, sender, bcc recipients, newsgroup recipients and so forth. This extra meta information is useful for legal e-discovery purposes.


Generally, when MailArchiva archives an envelope journal message, it stores both the envelope and the attached original message. When viewing the message, MailArchiva unpacks the message envelope and displays just the original message. Furthermore, at the time of archiving, MailArchiva examines the envelope and correctly indexes the journal fields contained within. The exact indexing behavior varies according to the specific type of envelope that is encountered.


An email archiving solution must at minimum support the envelope journaling operations outlined in the table below.

Operation Operation Description Comment MailArchiva 
 Archiving  Archiving of journal envelope data along with original messages  Storing original messages only will result in information loss.
 Import  Import journal envelope data  Importing original messages will not contain BCC and group recipient info.
 Parsing Parsing and indexing of journal envelope fields Support for a variety of journal envelope formats is needed. For example, Exchange 2007 envelopes are slightly different to Exchange 2013, and so forth.
 Search Search using journal recipient fields Search for emails with specific groups and BCC recipients.
 Export Export of both original and journal envelope data When responding to an e-Discovery records request, the full journal envelope may need to be supplied (if available). The reason being, the authorities may want to verify the actual recipients of a message at a particular time. Furthermore, if solution cannot export journal envelopes, the vendor has a form of lock-in, as it is impossible to switch archiving systems without experiencing data loss.


To search across the journal envelope fields, the user must be assigned a role with the "view bcc info" permission. The "view bcc info" permission is by default assigned to the Auditor role.

Journal envelope data is extracted into the MailArchiva fields depicted in the table below.

Field Comment Example
Journal To To Recipient. Not supported in Exchange 2003. journalto:user@mailarchiva.com
Journal BCC Blind Carbon Copy Recipient. Only Exchange 2007/2010/2013. Not supported in Exchange 2003. journalbcc:user@mailarchiva.com
Journal CC Carbon Copy Recipients. Only Exchange 2007/2010/2013. Not supported in Exchange 2003. journalcc:user@mailarchiva.com
Journal Recipients All recipients (Journal To + Journal BCC + Journal CC). journalrecipients:user@mailarchiva.com
Journal Sender Sender journalsender:user@mailarchiva.com
All It may include all journal fields if "view bcc info" permission is assigned all:user@mailarchiva.com
All Recipients It may include all journal recipients if "view bcc info" permission is assigned. allrecipients:user@mailarchiva.com
All Senders It may include all journal senders if "view bcc info" permission is assigned. allsenders:user@mailarchiva.com


In Exchange 2003, all recipients (to, cc and bcc) are indexed in the  Journal Recipients field. In Exchange 2007/2010/2013, they are separated into Journal BCC, Journal CC, and Journal To fields. No matter which version of Exchange, Journal Recipients always includes all recipients.

Microsoft Exchange


Exchange 2003

Exchange 2003 supports basic envelope journaling features. When envelope journaling is enabled, an envelope message is created with the original message as an attachment, before it is sent to the mail server. The envelope journal message comprises the following:


Sender: "External E-mail Support" <smtp:Administrator@contoso.com>
Message-ID: <72F2A6CEB90C7F4C8D051364BF4A9FA41A89@lag.contoso.com
"External E-mail Support" <smtp:Administrator@contoso.com>,
"Lene Aalling" <smtp:lenea@contoso.com>,
"Katja Heidemann" <smtp:katjaheidemann@contoso.com>,
"Doug Hite" <smtp:doughite@contoso.com>,
"Chris" <smtp:chris@contoso.com>,
"Katja folder" <smtp:Katjafolder@contoso.com>,
"Wide World Importers Folder" <smtp:WWIFolder@contoso.com>,
"Jeff Low" <smtp:JLow@contoso.com>


In Exchange 2003, envelope journaling is not enabled by default. When setting up Exchange 2003 journaling, ensure that envelope journaling has been enabled as described in the Exchange integration instructions. The exejcfg utility must have been executed.

Exchange 2007 - 2016 / Microsoft 365

In Exchange 2007 - 2016 / Microsoft 365, envelope journaling is similar to as described earlier, except the 2007/2010/2013 journal envelopes contain far more information. For one thing, MailArchiva is able to separate recipient information into Journal BCC, Journal CC, and Journal To fields. For more information on Exchange 2007 / 2010 / 2013 journal envelope format, please refer to http://technet.microsoft.com/en-us/library/bb331962.asp in the Microsoft Technet library.

Microsoft Information Rights Management (IRM) Support

MailArchiva is capable of parsing, indexing and displaying encrypted emails protected by Microsoft Information Rights Management (IRM). It will do so provided that journal report decryption is enabled in Microsoft Exchange / Office 365. With journal report decryption enabled, Microsoft 365 / Exchange attaches the decrypted version of an encrypted message to the journal report, enabling MailArchiva to parse out the decrypted version. To enable journal report decryption in Microsoft Exchange / Office 365, the following powershell command should be executed:


Set-IRMConfiguration -JournalReportDecryptionEnabled $true


Google audit envelopes 


MailArchiva EE v2.6 and higher support the display and indexing of Google Audit envelope messages. These messages contain meta data about an original attached message. The attached message contains a message.txt file, which contains the original message in RFC2822 format. When archiving a Google audit envelope, MailArchiva stores both the envelope and its attached original message.

IpSwitch IMail journaling 

When journaling is enabled in iMail, bcc recipients are added to a BCC field in the message. Furthermore, group recipients are automatically expanded in the To, From, CC and BCC fields. As one would expect, MailArchiva simply indexes this information in the Journal To, Journal Sender, Journal CC, and Journal BCC fields. 

Postfix/Sendmail journaling

Postfix and Sendmail, unfortunately, do not yet have the ability to send envelopes containing meta data about a message. Thus, it is impossible to determine who was BCC'd in a message. However, in most cases, it is possible to establish whether or not a person did in fact receive a message. This is due to the fact that MailArchiva indexes all SMTP/milter protocol sender and recipient info into Mail From and Rcpt-To fields, respectively. Furthermore, assuming the user is assigned a role with the "view bcc info" permission enabled, the fields All, All Recipients and All Senders will automatically include fields indexed in Mail From and Rcpt-To fields.

Additional MailArchiva headers

In additional to parsing and indexing journal envelopes, MailArchiva adds additional header information immediately before a message is archived.

Field Name Example Comment
X-MailArchiva-Archive-Time X-MailArchiva-Archive-Time: Tue, 1 Dec 2010 08:48:15 -0500 (EST) Time is taken from the system clock on the archive server. It is imperative to ensure that the time is set correctly on the server at all times. The use of an NTP time server is highly recommended.
X-MailArchiva-RcptTo X-MailArchiva-RcptTo: user@mailarchiva.com

Recipients extracted from the SMTP or milter protocols

X-MailArchiva-MailFrom X-MailArchiva-MailFrom: user@company.com Sender extracted from the SMTP or milter protocols
X-MailArchiva-Blob-Size X-MailArchiva-Blob-Size:23234 Total size of message including attachments (in bytes) uncompressed.

Cautionary note: acceptance of email timestamps

For all its genius and simplicity, in the modern era, the SMTP protocol is now regarded as flawed (its ubiquity has meant that all efforts to fundamentally change it have failed dismally). There are many reasons why the protocol is not meeting modern needs. One of them is that the information in an email can easily be spoofed. The smtp protocol assumes that the communicating clients should determine who sent a particular email and when.


For instance, the sent date of an email is often determined by the time set on the client machine. It remains a challenge for system administrators to ensure the time is set correctly on thousands of client machines on a network. Once more, it is even more improbable that the sent date is correct when the message comes from the outside, as one has little control over the sending parties' network environment.


For this reason, the sent dates on email messages should be regarded only as a guide. Also of interest are the receive headers that show when the message was received by the various mail servers along the journey to delivery. The timestamps on the receive headers are set by the relaying mail servers, thus are more likely to be accurate.


Finally, a more authoritative indication of when the communication took place comes from the timestamp set by the archive server. In MailArchiva's case, it is set in the field "X-MailArchiva-Archive-Time". Until such time as the SMTP protocol is fundamentally redesigned, auditors will need to put all the information together and decide on balance when a particular email was likely be sent.




© 2005 - 2024 ProProfs

Found this information useful? Visit mailarchiva.com to learn more about MailArchiva.