Перейти к концу метаданных
Переход к началу метаданных

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 2 Следующий »

These days many mail servers support envelope journalling in some form or fashion. The task of a mail server's journalling function is to ensure that an archive server has a copy of every message that passes through the server. It achieves this by forwarding journal messages to a temporary mailbox, where they are later picked up by an archive server such as Архива, or forwarded directly to the archive server via SMTP. The messages outputted by the journalling function are typically encapsulated in a message envelope.

An envelope is in most cases a normal RFC2822 email in of itself. The body of the message contains meta data about the original message that is being journalled. The original message is typically attached to the envelope message. The purpose of the envelope is to provide further information about the message such as the origin, destination, timestamp, recipients, sender, bcc recipients, newsgroup recipients and so forth. All this info can be put together to help auditors provide hard evidence.

Generally, when Архива archives an envelope journal message, it stores both the envelope and the attached original message. When viewing the message, Архива unpacks the message envelope and displays just the original message. Furthermore, at the time of archiving, Архива examines the envelope and correctly indexes the fields contained within. The exact indexing behaviour varies according to the specific type of envelope Архива encounters. More detail on this is provided below.]

If at any stage you need access to the original envelope, in Search settings, you can elect to export the Journal Message. With this option set, when exporting a message from Архива, the entire envelope along with the attached original message will be exported. You should be able to open the message up in a text editor and see the envelope data, along with the original message. If you don't, it can mean that envelope journalling is not functioning correctly or it is not enabled.

Exchange 2003

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



All BCC and newsgroup recipients are listed as recipients. Архива indexes these recipients in the "recipient" field. When searching for these expanded recipients, users must be assigned a role with the "view recipient" permission. They should select the "recipient" field in the search. When the view recipient permission is assigned, when viewing a message the "recipient" and "sender" fields will be displayed in the message header. This is by design as these fields show who actually received the message.
Note: Granting users the "view recipient" permission will make it possible for users to search both the group recipient and BCC recipient data. With Exchange 2003, it is not possible to separate this information due to a limited envelope journal format. At the very least, it is possible to see who actually received the message and this should be good enough for legal purposes (although, don't take our word for it, we are not legal experts!).

Note: in Exchange 2003, envelope Journalling is not enabled by default. When setting up Exchange 2003 journalling, ensure that you have enable envelope journalling as described in the Administration Guide. You need to have downloaded the exejcfg utility and have executed it!

Exchange 2007/2010

In Exchange 2007/2010, envelope journalling is similar to as described earlier, except the 2007/2010 journal envelopes contain far more information. For one thing, Архива is able to separate BCC and group recipient information, so this information is indexed as one would expect in the TO and BCC fields (they are also available in the recipient fields). For more information on Exchange 2007/2010 journal envelope format, please refer to http://technet.microsoft.com/en-us/library/bb331962.asp in the Microsoft Technet library.
An example Exchange 2007 / 2010 envelope consists of the following:


Google Audit Envelopes

Архива 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, Архива stores both the envelope and its attached original message.

IpSwitch IMail Journaling

When journalling is enabled in iMail, bcc recipients are added to a BCC field in the message. Furthermore, groups recipients are automatically expanded in the To, From, CC and BCC fields. As one would expect, Архива simply indexes this information in the correct fields.

Postfix/Sendmail journaling

Postfix and sendmail don't offer envelope journal or BCC data. Архива has a workaround that may help you obtain further information from these mails servers. When an email addressed to recipient A and B is handled by Postfix/Sendmail, the mail is sent to Архива twice, once for each recipient. It is possible to configure Архива such that it caches this recipient information between each connection and updates the message with the additional recipient information. The combined rcptto information is indexed in the "recipient" field. Thus, it is possible to search for the actual recipients of a message by using the recipient field. In order to search using the recipient field, the view recipient permission must be added to the user's role. To enable this option, in Configuration->Archive Settings, check "Combine RCPTTO info for identical messages".


Additional Архива Headers

In additional to parsing and indexing envelope journalled message, Архива adds some additional header information:
The exact archive time:
X-MailArchiva-Archive-Time: Tue, 1 Dec 2010 08:48:15 -0500 (EST)
Note: The time used is taken from the system clock of 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: archive@mailarchiva.com
This is the additional rcptto data taken from the SMTP or milter protocols. It provides additional information about to whom the message actually sent to. Refer to the section on Postfix/Sendmail Journalling above for more information on how to get the most of out this field.
This is the additional mail from data taken from the SMTP or milter protocols
X-MailArchiva-MailFrom: admin@company.com

Note On 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 time 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 the sent date is correct when the message comes from the outside as you have no control over the sending parties network environment.
For this reason, the sent dates on email messsages should be regarded as only 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 Архива'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.

  • Ни одной