An email message that contains unsupported encoded characters in the subject line is not delivered in an Exchange Server 2010 environment

Symptoms

Consider the following scenario:

• You send an email message by using a Microsoft Exchange Server 2010 mailbox.

• The subject line of the email message contains unsupported encoded characters, such as ISO-2022-JP-2 encoded characters.

In this scenario, the email message is not delivered. Additionally, you do not receive a non-delivery report (NDR) message.

Cause

This issue occurs because Exchange Server 2010 does not process an email message if the subject line contains unsupported encoded characters. Additionally, an exception occurs when Exchange Server 2010 tries to generate a NDR message.

Resolution

To resolve this issue, install the following update rollup:

2509910 Description of Update Rollup 4 for Exchange Server 2010 Service Pack 1
After you apply this update rollup, you will receive an NDR message when you send an email message that contains unsupported encoded characters in the subject line. Additionally, a new feature is available to enable a fallback to use the default character set in the configuration file. If you enable this feature, email messages that have unsupported encoded characters in the subject line can be delivered. To enable this feature, follow these steps:

1. Open the EdgeTransport.exe.config file in Notepad.
   
   Note By default, the EdgeTransport.exe.config file is located in the following folder: C:\Program Files\Microsoft\Exchange Server\V14\Bin
   

2. Add the following configuration elements under the configuration element:
   
   
   
   Note The only difference in the element is "Version." For example, use "Version=14.1.214.0" for Exchange Server 2010 Service Pack 1, "Version=14.2.214.0" for Exchange Server 2010 Service Pack 2, or "Version=14.3.214.0" for Exchange Server 2010 Service Pack 3.
   
   

   <configSections>
       <section name="CTS" type="Microsoft.Exchange.Data.Internal.CtsConfigurationSection, Microsoft.Exchange.Data.Common, Version=14.2.214.0, Culture=Neutral, PublicKeyToken=31bf3856ad364e35" />
   </configSections>
   <CTS>
       <Globalization>
         <FallbackToDefaultCharset Fallback="true"/>
         <DefaultCulture Culture="ja"/>
       </Globalization>
   </CTS>

   Notes

   • The configSections section must be the first element of the configuration element which is enforced by .NET. If not, the Transport service stops responding when it start.

   • The version, culture, and public token of the Microsoft.Exchange.Data.Common assembly must be correct. You can find them from the Global Assembly Cache (GAC).

   • The FallbackToDefaultCharset element is used to turn on or turn off this feature. You can turn on or turn off this feature by setting the Fallback attribute to true or false.

   • The DefaultCulture element is to specify a fallback culture if the character set on the email message is not supported. You must set the Culture attribute to a valid culture name. If not, Exchange will use the culture of the current thread as the fallback culture. In the sample configuration, the fallback culture is set to "ja", which could preserve most of the characters for unsupported character set such as "ISO-2022-JP-2."

3. Save the EdgeTransport.exe.config file.

4. Restart the Transport service to take effect.

Note The configuration file must be edited carefully. There are no traces or event logs for diagnostics. The feature will not work or work as expected if there is a typo in the configuration file. Also notice that for a message that has unsupported charset, we will not guarantee anything with the message when it is received and we will not guarantee the fidelity of any messages that is caused by this message when it is received.

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.