Ade Famoti's Exchange blog

Exchange Journaling: Literacy issues

2006-05-16T02:35:00Z

When you implement Exchange journaling, the content-identifer (PR_CONTENT_IDENTIFIER) of the journal messages are expected to be "ExjournalData", or with envelope journaled messages "ExjournalReport"

This header "Content-Identifier" is misspelled in Exchange to "Content-Identifer". Notice the missing "i"

Received: from server.foo.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 14:01:33 -0500

Subject: FW: Testing 123

Date: Wed, 15 Jun 2005 14:01:29 -0500

Message-ID: 4B30D54FD6FB64FBF3A8F0B07C88D1DD0A1@server.foo.com

Content-Identifer: ExJournalReport

This content-identifier header is popularly used by some 3rd party journaling and compliance vendors to "truly" identify a journal copy of a message. This sometimes causes issues where some 3rd party vendor applications fail to process journaled messages. You will only experience this, if your 3rd party archival vendor of choice relies on this header. Typically, all messages sent to them should be archived anyway.

To mitigate this issue on Exchange 2003, download the Exchange 2003 service pack ( SP2), to put your store and other binaries at 6.5.7638. We fixed this literacy issue that can potentially put your off track on your email compliancy.

Download SP2 here:

Regulatory Compliance with Exchange Server 2003 journaling

2006-05-03T02:55:00Z

Some enterprises have implemented the Exchange journaling feature, to meet some of their regulartory compliance needs. Some of the well-known U.S. regulations with requirements that may rely on Exchange 2003 archiving/ journaling technology.

Some of these include, the Sarbanes-Oxley Act, SEC Rule 17A-4, NASD 3110 and 3111, Gramm-Leach-Bliley Act (GLBA)(Financial Institution Privacy Protection Act of 2001, Financial Institution Privacy Protection Act of 2003) , Healthcare Insurance Portability and Accountability Act of 1996 (HIPAA), Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001 (Patriot Act) e.t.c

Read Supporting Regulatory Compliance with Exchange Server 2003 to learn about the Current Regulatory Environment and how Exchange can play a role.

The whitepaper states: "Numerous federal regulations affect businesses today. Financial services organizations now face rules and regulations established by the Securities and Exchange Commission (SEC) and National Association of Securities Dealers (NASD), which have long overseen the financial industry. The healthcare industry has rushed to meet the requirements of the HIPAA.

Other broad-reaching regulations, such as Gramm–Leach–Bliley (GLBA) and SOX, require businesses in other industries to focus on how they safeguard, disseminate, store, and track financial information. In fact, many states have enacted regulations that overlay federal regulations. Therefore, it is important that your organization complies with any applicable state, district, and industry laws as well as with the pertinent federal regulations.

Many of these regulations affect how, where, and how long organizations must maintain electronic records, including e-mail. Regulatory compliance is complex and should be overseen by legal counsel. The following regulations pertain to many organizations and present a simple overview of today’s regulatory environment.

Sarbanes–Oxley Act

The Sarbanes–Oxley Act requires that:

· Executives of publicly traded companies certify the validity of the company’s financial statements

· Financial control and risk mitigation processes be documented and verified by independent auditors

· Companies implement extensive policies, procedures, and tools to prevent fraudulent activities

SEC Rule 17A-4

SEC Rule 17A- 4 requires that:

· Original copies of all communications, such as interoffice memoranda and communications, be preserved for a period of no less than three years, the first two in an easily accessible location

· Records be maintained, preserved, and available to be produced or reproduced using either micrographic media (such as microfilm or microfiche) or electronic storage media (any digital storage medium or system)

Gramm-Leach-Bliley Act

The Gramm–Leach–Bliley Act (Financial Institution Privacy Protection Act of 2001), amended in 2003 to enhance the protection of nonpublic personal information, requires that financial records be properly secured, safeguarded, and eventually disposed of in a manner that completely destroys the information so that it cannot be further accessed.

Healthcare Insurance Portability and Accountability Act of 1996

The Healthcare Insurance Portability and Accountability Act of 1996 requires that:

· Security standards be adopted to control who can access health information to provide audit trails for computerized record systems and to meet the needs and capabilities of small and rural health care providers

· Health data is isolated and inaccessible to unauthorized access

· Transmission of health information is physically, electronically, and administratively safeguarded to ensure the confidentiality of data"

Download the Exchange 2003 journaling whitepaper today, and learn how the archiving features of Exchange, and how it can assist your regulatory compliance objectives.

What happens to journaled mail when it NDRs ?

2006-04-22T00:49:00Z

If you're implementing Exchange envelope journaling, then you've probably wondered what happens to journaled messages that cannot be delivered or NDR.

Journaled or archived messages are considered as system messages. What this means is, if your journal messages result in NDRs (Non-Deliverable Reports), then they might blackhole or dissapear.

Okay, so you're using this feature to meet regulatory compliance or maybe some other legal requirement. It's important to try as best as you can to preserve all archived mail, even the ones that result in NDRs. When a journal message is in transit, the RFC 2821 sender is a null address or < >, so is the return path. What this means is, if a journal messages has to be returned undeliverabl, it has no where to go to since the sender is < >. This will cause the message to end up in the badmail directory.

In Exchange 2003 SP1, the mailroo\vsi1\badmail folder is disabled, and does not receive undeliverable content. You can enable the badmail directory to start receiving undeliverable content, but cautiously do this since it may open you up for DoS on the badmail directory if you are spammed heavily from the internet. Enabling badmail will give you the opportunity to still have a copy of the journaled messages

X-headers in envelope journaling

2006-04-05T22:45:00Z

If you are implementing Exchange 2003 envelope journaling, nad using SMTP + auto-forward rules to get the archived messages to a 3rd party archival, the X-headers on the archived messages may not be preserved.

When the journaled messages reach the journal-mailbox, you probably have an auto-forward server side rule that kicks it out the the internet. When this happens (auto forward), the archived message is essentially embedded in a new message. This process leaves the custom or X-headers (x-spam-score, x-message-is-clean e.t.c) stripped off the attached journal message.

We decided to fix this in the code, to preserve these X-headers if you happen to be have needs for them in your regulatory compliance objectives. If you are running Exchange 2003, you need service pack 2 (SP2) 6.5.7638.1, then install the hotfix from KB 899023, which will put you at store.exe 6.5.7651. If you have a store build at 6.5.7651, then you need not apply this fix.

Journaled messages are system messages

2006-04-05T04:36:00Z

Be careful when you edit or change your connnector configurations. If you have journaling enabled, and sending off to a 3rd party archive storage, make sure that you have "system" messages allowed on the content-restrictions tab of the connector properties.

Journaled messages are treated as system messages, and if the connector being used prohibits system messages, the messages blackhole and are lost.

e.g you have a connector with address space of frontbridge.com, where all your journaled messages are archived, then its imperative to have system messages allowed on that connector.

Regulatory compliance using Exchange hosted archive

2006-04-05T04:34:00Z

Frontbridge was acquired a while back by Microsoft. Recently it was announced that Microsoft Exchange Hosted Services will now take the front line for hosted services including compliancy, data rentention, encryption, confidentiality e.t.c

The hosted archive should be particularly interesting because of its powerful capabilities. Read more on http://www.microsoft.com/exchange/services/archive.mspx

Envelope Journaling results in blank recipients - dont panic !

2006-04-03T22:19:00Z

If you have implemented Exchange 2003 envelope journaling , then you may find this issue interesting.

When you change the JournalRecipient mailbox on your recipents' stores, you may notice that some envelope journal reports contain a blank recipient list. Exchange has not gone wild on your regulatory compliance designs. Dont panic :-).

You may observe multiple copies of envelope journal messages being generated between teh old and newly assigned journal mailbox. Some will contain the blank recipient list in the envelope journal report, but at least one will contain the full list of all recipient that received the message. So there is no data loss here.

What you're seeing is essentially a 15 minute configuration TTL lag in Active Directory. Basically, this issue rectifies itself in ~ 15 or less. Within this time period, your Exchange server has knowledge of your old journalRecipient mailbox and the newly assigned journalRecipient mailbox.

The blank report section of the envelope journal message may resemble this:

Sender: "Jane Doe" <smtp:JaneDoe@contoso.com>
Message-ID: <2006xxxyyyyzzzz0@server.contoso.com>
Recipients:

A normal envelope journal report should look like: a message from Jane Doe to John Doe

Sender: "Jane Doe" <smtp:JaneDoe@contoso.com>
Message-ID: <2006xxxyyyyzzzz0@server.contoso.com>
Recipients:

"John Doe" JohnDoe@contoso.org

Ensure that your old journalmailbox is still active for at least 15 minutes when you assign a new journal mailbox to receive the archived emails. Another way to mitigate this 15 minute lag, is to pause the SMTP virtual server on the journal mailbox server. This causes the server to not receive inbound mail from other servers, but continue to process outbound and messages already in progress. After this time, can then allow mailbox servers or internet bridgeheads to send archived messages onwards to the journal server.

Exchange 2003 SP2 and UUENCODE attachments

2005-12-16T19:57:00Z

We got lots of complains about weird and garbled attachments after installing SP2, with gibberish text appearing in the message body. Yes, SP2 does change the way certain uuencode message are now rendered to the client. It's even worth noting that this change is not entirely new, and was also included in Exchange 2000 since the April 2004 rollup, and Exchange 2003 post SP1 hotfixes. The first thing you could use to identify this issue, is that the message contains both a "MIME Version" header, and the body of the messag starts with the word "BEGIN"

In Exchange 2003 SP2 and recent rollup builds of Exchange 2000, when a uuencode message is incorrectly tagged with a MIME version header, then the uuencode text is treated as MIME. therefore, the text shows in the body of the message as garbled. In essence, the message is combining two different internet body formats by combining a MIME version 1.0 header within a UUENCODED message. Basically, both standards (MIME and UUENCODE) cannot be combined in the same message.

The word UUENCODE is derived from “Unix to Unix encoding”. A UUENCODED message can be identified by the first word in the message “BEGIN” .

e.g BEGIN <mode> <file>
The <mode> is the file's read/write/execute permissions as three octal digits, and <file> output name to write the decoded data.

The “MIME Version 1.0” header on the other hand, usually identifies that a message is a MIME (Multipurpose Internet Mail Extensions) message, and in compliance with RFC 2045.

e.g version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

To lend some more history to this change. In the past, Exchange erroneously treated normal MIME messages that started with the word "BEGIN'
as UUENCODED messages, thus resulting in normal textual messages appearing as attachments.
For example, if you composed a message as such:

From: John@foobar.com
To: Jane@foo.net
Subject: This is a test

Begin please acknowledge receipt of this message

Below is a sample UUENCODE message that also has a MIME Version 1.0 header

Date: Fri, 2 Dec 2005 14:21:33 +1100 (EDT)

John Doe <JohnDoe@contoso.com>

Message-Id: <200512020321.server.domain.com>

To: Jane Doe@foo.com

Subject: View the attachment

Mime-Version: 1.0

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

Return-Path: JohnDoe@contoso.com

X-OriginalArrivalTime: 02 Dec 2005 03:21:31.0901 (UTC) FILETIME=[7DDA6AD0:01C5F6EF]

Here is your attachment report

begin 664 02122005142133.txt

M:6-L;W)P+G`@92L@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@

M("`@(#,N-BXV($EN=F5N=&]R>2!$971A:6P@8GD@3&]C871I;VX@("`@("`@

M("`@("`@("`@("`@("`@("`@("`@("`@("`@($1A=&4Z(#`R+S$R+S`U#0I0

M86P-"E-I=&4@("`@($QO8V%T:6]N($ET96T@3G5M8F5R("`@("`@("!2968@

M("`@("`@("`@("`@("`@54T@(%%T>2!/;B!(86YD($-R96%T960@($5X<&ER

M92`@($%S<V%Y("4@1W)A9&4@4W1A='5S("`@079A:6P@3F5T($]V<DES#0HM

M+2TM+2TM+2`M+2TM+2TM+2`M+2TM+2TM+2TM+2TM+2TM+2T@+2TM+2TM+2TM

M+2TM+2TM+2TM("TM("TM+2TM+2TM+2TM+2`M+2TM+2TM+2`M+2TM+2TM+2`M

M+2TM+2TM("TM+2TM("TM+2TM+2TM("TM+2TM("TM+2`M+2TM+0T*,C`P,"`@

M("`@1C`P,2`@("`@,3`P,#`@("`@("`@("`@("`@("`@("`@("`@("`@("`@

M("`@("!%02`@("`@("`@+3$X+C`@,#(O,#<O,#`@("`@("`@("`@("`P+C`P

=("`@("`@("`@("`@("`@($)A=&-H($E$.@T*#!H@

`

end

The solution here is to configure the non-Exchange server (usually UNIX) sending to Exchange, not to add the "MIME Version" header to UUENCODE message, or alternatively configure to send pure MIME messages to Exchange.

See http://www.ietf.org/rfc/rfc2045.txt and http://support.microsoft.com/default.aspx?scid=kb;en-us;836555