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.
 

Search

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.
 

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
<mailto:72F2A6CEB90C7F4C8D051364BF4A9FA41A89@lag.contoso.com>>
Recipients:
"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>

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:

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.
 

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.