Exchange Stripping Attachments for Web Based Email Clients

Issue

I had a VERY weird problem with a customers exchange server when sending attachments. When sending an email an attachment to some web mail systems (for example http://mail.iinet.net.au) the attachments do not appear under the web mail system. However sending emails to other windows email servers running Exchange and opening the email with Outlook or Outlook Web Access the attachment comes up fine.

- There are no smarthosts in front of this exchange server, its relaying directly to the Internet using MX records.

- This company only has a single server running the exchange mailbox, hub transport and client access roles.

- The issue is not with Microsoft Office Outlook as it occurs for both outlook and outlook web access.

- The same attachments can be sent from another exchange organisation. If I send the email to my home exchange server, then forward it onto the correct iinet address, the iinet address receives it correctly.

- No Transport Agents are running on the exchange server with rules configured, eg the transport rules or journaling rules agents.

- The exchange organisation is running exchange 2007 with service pack 1. Other exchange 2007 organisations running service pack 1 do not have the issue - I tested.

- Every mailbox user in the exchange organisation is experiencing the problem.

- All attachments are experiencing the problem regardless of the attachment format.

When a user sent an email to a web mail provider the attachment was not available for download even though web mail identifies there were attachments in the email. Please click to enlarge.



When a user such as myself sends an email from another exchange organisation, the email goes through fine and the attachment is downloadable. See the screenshot below - click to enlarge.



Resolution

The problem was identified using Pipeline Logging on the hub transport server. This pushes out email message body to a text file allowing an administrator to review. Pipeline logging was enabled on the hub transport user for a user experiancing problems.

- Open Exchange Management Shell (EMS).

- Run the following cmdlet in EMS:

Set-TransportServer <hub_server_name> -PipelineTracingSenderAddress <smtpaddress>

Note: Replace the <smtpaddress> with a problematic sender address.

- Run the following cmdlet in EMS:

Set-TransportServer <hub_server_name> -PipelineTracingEnabled $True

- Send a plain text email from the user to the iinet email address with an attachment.

- Disable Pipeline logging again for that user account with:

Set-TransportServer <hub_server_name> -PipelineTracingEnabled $False

X-CreatedBy: MessageSnapshot-Begin injected headers

X-MessageSnapshot-UTC-Time: 2010-07-12T06:38:36.291Z

X-MessageSnapshot-Record-Id: 3266

X-MessageSnapshot-Source: OnRoutedMessage,Journaling Agent

X-Sender: user@badexchangeorganisation.com

X-Receiver: user@iinet.net.au

X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers

Received: from CAPS-PER-EX1.badexchangeorganisation ([127.0.0.1]) by caps-per-ex1

([127.0.0.1]) with mapi; Mon, 12 Jul 2010 14:38:35 +0800

Content-Type: application/ms-tnef; name="winmail.dat"

Content-Transfer-Encoding: binaryFrom: Matthew Sampson

To: "user@iinet.net.au"

Date: Mon, 12 Jul 2010 14:38:35 +0800

Subject: Plain Text Test Email

Thread-Topic: Plain Text Test Email

Thread-Index: AcshjMv1dlpmCgONQJ2XofbMlypxSw==

Message-ID: <4dac02e2e52f584ca7a90ddcfee6f89204bfd55d9f@caps-per-ex1>

Accept-Language: en-US, en-AU

Content-Language: en-US

X-MS-Has-Attach: yes

What gave the problem away was the email had a winmail.dat file attached identified in the pipeline log, even though we specified plain text. winmail.dat files are created by outlook whenever an email is sent in RTF (Rich Text Format). Outlook and Outlook Web Access deal with them fine but other mail clients sometimes have problems.

It turned out that the Exchange Server was converting the emails to rich text format meaning many web based email clients could not display the attachment correctly.

The problem was resolved by performing the following steps:

Get-RemoteDomain | fl

Check if the value of TNEFEnabled is set to true. If yes, please run the following cmdlet to correct it:

Set-RemoteDomain "Default" -TNEFEnabled $null