今回は Exchange 2007 / 2010 と Exchange 2013 の混在環境で NDR (バウンス メッセージ) を返すトランスポート ルールを構成する際の注意点についてご紹介いたします。本内容に該当している場合、Exchange 2007 / 2010 側で該当ルールを処理して NDR を返す際に Microsoft Exchange Transport サービスが不正終了する現象が発生してしまいます。

現象について
Exchange 2007 / 2010 では NDR を返すトランスポート ルールを構成する際に応答メッセージ (RejectMessageReasonText) に指定可能な文字列は US-ASCII のみであり、Exchange 管理コンソールや Exchange 管理シェルから応答メッセージ (RejectMessageReasonText) に日本語などを指定しようとするとエラーが発生して設定自体が出来ないように制御されていました。一方で Exchange 2013 では後述の「参考」で記載するように動作が変更されていることもあり、応答メッセージ (RejectMessageReasonText) に日本語などの文字列も指定出来るようになっています。

なお、トランスポート ルールの設定内容は Active Directory 上で保持して Exchange 組織内で共通で管理されており、Exchange 2007 / 2010 / 2013 はいずれも Active Directory からトランスポート ルールの設定を読み込んで処理しています。このため、Exchange 2007 / 2010 と Exchange 2013 の混在環境で Exchange 2013 から応答メッセージ (RejectMessageReasonText) に日本語などを使用したトランスポート ルールを構成した場合、該当ルールを Exchange 2007 / 2010 が処理すると意図されていないデータであると判断して内部エラーが発生し、イベント ログに以下のエラーが記録されて Microsoft Exchange Transport サービスが不正終了します。

ログの名前 : Application
ソース : MSExchangeTransport
イベント ID : 10003
タスクのカテゴリ: PoisonMessage
レベル : エラー
説明:
次のコール スタックでメッセージを処理しているときに、トランスポート プロセスに失敗しました。System.FormatException: 応答用のテキストに含めることができるのは、US-ASCII 文字だけです。
場所 Microsoft.Exchange.Data.Transport.Smtp.SmtpResponse..ctor(String statusCode, String enhancedStatusCode, String[] statusText)
場所 Microsoft.Exchange.MessagingPolicies.Rules.RejectMessage.Reject(TransportRulesEvaluationContext context, String status, String enhancedStatus, String reason)
場所 Microsoft.Exchange.MessagingPolicies.Rules.RulesEvaluator.ExecuteActions()
場所 Microsoft.Exchange.MessagingPolicies.Rules.RulesEvaluator.Run()
場所 Microsoft.Exchange.MessagingPolicies.Rules.TransportRuleCollection.Run(TransportRulesEvaluationContext context)
場所 Microsoft.Exchange.MessagingPolicies.TransportRuleAgent.TransportRuleAgent.OnRoutedMessageHandler(RoutedMessageEventSource source, QueuedMessageEventArgs args)
場所 Microsoft.Exchange.Data.Transport.Routing.RoutingAgent.Invoke(String eventTopic, Object source, Object e)
場所 Microsoft.Exchange.Data.Transport.Internal.MExRuntime.Dispatcher.Invoke(MExSession session)
場所 Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExSession.AsyncInvoke(Object state)
場所 Microsoft.Exchange.Data.Transport.Internal.MExRuntime.MExSession.BeginInvoke(String topic, Object source, Object e, AsyncCallback callback, Object callbackState)
場所 Microsoft.Exchange.Transport.Categorizer.MExEvents.RaiseEvent(MExSession mexSession, String eventTopic, AsyncCallback callback, Object state, Object[] contexts)
場所 Microsoft.Exchange.Transport.Categorizer.MExEvents.RaiseOnRoutedMessage(TaskContext context, AsyncCallback callback, MailItem mailItem)
場所 Microsoft.Exchange.Transport.Categorizer.CategorizerComponent.Stage5OnRoutedMessage(TransportMailItem transportMailItem, TaskContext taskContext)
場所 Microsoft.Exchange.Transport.Categorizer.

Exchange 2007 / 2010 と Exchange 2013 の混在環境で NDR を返すトランスポート ルールを構成する際には Exchange 2013 から設定する場合でも応答メッセージ (RejectMessageReasonText) は US-ASCII のみの文字列にしていただけますようお願いいたします。

参考 (Exchange 2013 での動作変更)
以下の TechNet に記載されている通り、Exchange Server が生成する NDR の本文は "ユーザー情報セクション" と "管理者向けの診断情報セクション" で構成されています。"管理者向けの診断情報セクション" の SMTP 応答部分は US-ASCII のみ使用することができますが、"ユーザー情報セクション" のテキストでは日本語など US-ASCII 以外の文字も使用することができます。

Title: DSN と NDR
URL: http://technet.microsoft.com/ja-jp/library/bb232118(v=exchg.150).aspx

例えば、以下のようなトランスポート ルールを構成した上で New-SystemMessage でカスタム DSN メッセージも登録してテキスト内容をカスタマイズしていることを考えます。

・トランスポート ルール

・カスタム DSN メッセージ

Exchagne 2007 / 2010 ではトランスポート ルールの RejectMessageReasonText で指定した文字列は拡張状態コードと共に "管理者向けの診断情報セクション" の SMTP 応答部分に記載されていました。

ただし、Exchange 2013 では RejectMessageReasonText で指定した文字列は "ユーザー情報セクション" のテキストに記載されるように動作が変更されており、これにより Exchange 2013 では RejectMessageReasonText に日本語などの文字列も指定できるようになっています。

なお、Exchange 2013 CU6 以前ではトランスポート ルールで NDR を返した場合にカスタム DSN メッセージで登録したテキスト内容が表示されない不具合がござました。本不具合は Exchange 2013 CU7 で修正されておりますので、Exchange 2013 でカスタム DSN メッセージを登録する場合にはご注意ください。

Title: RejectMessageReasonText in transport rule appears in the user section of a DSN in Exchange Server 2013
URL: https://support.microsoft.com/kb/3003986/en-us

・Exchange 2013 CU6 以前の環境でトランスポート ルールにより生成された NDR

こんにちは。

今回は Exchange Server の配布グループについてお話しします。

Exchange Server (Exchange Online 含む) の配布グループは、所属部署ごとなどのある条件に合致するメンバーにまとめてメールを配信する場合に便利な機能です。

この配布グループは、主に Exchange 組織内での利用を想定して用意されていますので、既定では外部からのメッセージは受信できない状態となっています。

送信者の制限の設定箇所は、Exchange 2010、Exchange 2013 のそれぞれで以下で確認する事ができます。Exchange Online の場合は、Exchange 2013 と同じです。

　　　　　　　　　　　　図1 Exchange 2010 の画面

　　　　　　　　　　　　図2 Exchange 2013 の画面

管理シェルからは以下で確認できます。(Exchange 2010/2013/Online 共通)

この設定を変更 (RequireSenderAuthenticationEnabled を False に変更) することで、外部から送信されたメッセージも受信できるようになります。
また、配布グループには、Exchange 組織外の外部アドレスを連絡先として作成し、グループのメンバとして登録する事ができます。

そのため、上記の設定Exchange 組織外からも受信を行うようにすることであたかもメーリング リストの様に利用できます。

　　　　　図3  Exchange 組織外から配布グループ宛てに送付

図3 の様に、組織外 (@contoso.com) から連絡先 (@contoso.com、@fourthcoffee.com) を含む配布グループ宛てにメッセージを送信すると、Exchange Server で展開されメンバへと配信されます。

この際に外部のメンバ (@contoso.com、@forthcoffee.com) 宛に転送するときの "なりすまし" とみなされることを防ぐために、既定ではそのメールの from には配布グループの SMTP アドレス (@microsoft.com) が設定されます。

！ここで注意が必要です！

配布グループに連絡先として登録した外部アドレスのユーザーが、何かしらの要因により受信できない等の場合は、そのユーザーのメールサーバーで配信不能通知 (NDR) が生成されます。

この時、生成された NDR の返送先は、一般的に from となっている配布グループのアドレスに送信されます。

配布グループに NDR が送付された場合、その NDR が Exchange Server で NDR であると識別できる形式であれば、NDR を配布グループに配信しないので破棄されますが、NDR として認識できない場合は、NDR の転送試行により NDR の生成を繰り返してしまう場合があります。

ループの発生を未然に防ぐためには？

このような問題が発生しないように、Exchange Server の配布グループには以下の2つの設定が用意されており、既定値はそれぞれ以下の通りです。

　ReportToManagerEnabled    : False

　ReportToOriginatorEnabled : True

これらは、NDR などの Delivery Status Notification (DSN) の送付先の設定になります。

上記の通り、既定値では、送信者に DSN が返され、管理者には送付はされません。

この設定を以下の様に変更する事で、NDR などの DSN が from に返されることなく、配布グループの管理者に返されるようになりますので、意図しないメッセージのループが発生する事を防ぐことができます。

　Set-DistributionGroup -Identity <配布グループ名> -ReportToManagerEnabled:True -ReportToOriginatorEnabled:$False

Exchange Server の配布グループは、組織内のグループ アドレスとして利用されることを想定されており、メーリング リストは、メール アドレスのドメインを意識することなく利用できます。

今回ご案内したように、上記の様に設定を変更する事で、配布グループもメーリング リストの様に利用できますが、Exchange Server の配布グループと一般的なメーリング リストは似て非なるものです。

配布グループをメーリング リストとして運用されているお客様も多いと思われますので、一度設定を見直してみてはいかがでしょうか。

今回、Exchange チームは複数のリリースを発表しました。Exchange Server 2013、2010、2007 の更新プログラムが含まれます。現在、Microsoft ダウンロード センターから以下のパッケージが入手可能です。

Ÿ  Exchange Server 2013 の累積更新プログラム 7

Ÿ  Exchange Server 2013 の累積更新プログラム 7 の UM 言語パック

Ÿ  Exchange Server 2010 SP3 の更新プログラムのロールアップ 8

Ÿ  Exchange Server 2007 SP3 の更新プログラムのロールアップ 15

上記のリリースは、対応する各製品で利用できる最新の修正プログラムで、お客様からご報告いただいた問題の修正と、小規模な機能強化が含まれています。それぞれの製品バージョンの累積更新プログラムと更新プログラムのロールアップには、先日導入されたロシアのタイム ゾーンに関する重要な更新と、MS14-075 で特定されたセキュリティの問題に対する修正が含まれます。さらに今回、MS14-075 について Exchange Server 2013 Service Pack 1 のセキュリティ更新プログラムと Exchange Server 2013 の累積更新プログラム 6 のセキュリティ更新プログラムもリリースされました。

Exchange Server 2013 の累積更新プログラム 7 には、Exchange Server 2013 への移行をより簡単にするための更新が含まれます。内容は以下のとおりです。

Ÿ  Exchange Server 2013 での 250,000 のパブリック フォルダーを含むパブリック フォルダー階層のサポート

Ÿ  大規模な Exchange Server 2013 環境における OAB の配布 (英語) のサポート強化

複数の異なるバージョンの Exchange が共存する環境でパブリック フォルダーを展開しているお客様は、Brian Day のブログ記事で詳細をご確認ください。

累積更新プログラム 7 には、バックアップに関する小規模な機能強化が含まれます。Exchange データベースをバックアップしているお客様には、早急に累積更新プログラム 7 にアップグレードし、その後、再度完全なバックアップを実行していただくようお勧めします。今回の機能強化により、以前のバックアップからデータベースを復元する際に発生するおそれのあった問題が解消されます。

Exchange 2013 に関する最新の情報および発表内容については、TechNet の「Exchange 2013 の新機能」の記事、リリース ノート、Exchange 2013 の製品ドキュメントをご覧ください。

累積更新プログラム 7 には、Active Directory のスキーマおよび構成について、Exchange に関連する更新が含まれています。Active Directory のスキーマ拡張と構成の詳細については、Exchange 2013 製品ドキュメントの「Active Directory とドメインを準備する」を参照してください。

要確認: ハイブリッド展開 (オンプレミスとクラウドの両方で Exchange を展開) のお客様、および Exchange Online Archiving (EOA) をオンプレミスの Exchange 展開でご利用のお客様は、最新の累積更新プログラムを展開する必要があります。

最新情報 (2014 年 12 月 12 日) Exchange Server 2010 SP3 の更新プログラムのロールアップ 8 の初回リリースで発見された不具合が解決され、Microsoft ダウンロード センターにて提供を再開しました。Exchange から Outlook への接続に影響する問題が発生していましたが、更新後の RU8 パッケージでは修正されています。この問題は MAPI RPC レイヤーのみに存在したため、問題を切り分けて更新版の RU8 パッケージを迅速に提供することができました。更新版 RU8 パッケージのバージョン番号は 14.03.0224.002 です。ダウンロードしたパッケージが更新版であるかどうかを確認する必要がある場合にご参照ください。Exchange Server 2013 および 2007 の更新プログラムはこの不具合の影響を受けなかったため、更新はありません。 最新情報 (2014 年 12 月 10 日) Exchange Server 2010 SP3 の更新プログラムのロールアップ 8 (RU8) で問題が検出されました。この更新プログラムは既に配信が停止されており、新しい RU8 がリリースされるまでダウンロード センターから入手することはできません。お客様には、新しいバージョンの RU8 が公開されるまで、この更新プログラムを展開なさらないようお願いいたします。既に展開を開始している場合には、ロールバックを行ってください。 こ の問題は Exchange に接続する Outlook の機能に影響するため、マイクロソフトでは RU8 を撤回し、問題を解決するべく対応を進めています。原因の特定、修正、検証が済みしだい、更新されたパッケージを提供する予定です。RU8 に関する最新情報については、今後もこのブログ記事でご案内します。 これは Exchange Server 2010 SP3 RU8 の更新プログラムにのみ見られる問題です。その他の更新プログラムは問題なくご利用いただけますので、引き続きパッケージの展開をお勧めします。 Exchange チーム

対象: Office 365 Enterprise 管理者

(この記事は 2014 年 9 月 10 日に The Exchange Team Blog に投稿された記事 Keep your Federation Trust up-to-date の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

マイクロソフトでは、高い可用性と安全性を備えた環境を維持するための取り組みの一環として、Office 365 における証明書を定期的に更新しています。2014 年 9 月 23 日に、Microsoft Federation Gateway の証明書が変更される予定です。これにより、一部のお客様はサポート技術情報記事 2928514 で詳しく説明されているような影響を受ける可能性がありますが、サービス中断は簡単に回避いただくことが可能です。

影響のあるお客様

今回の証明書の変更によって、Microsoft Federation Gateway をご利用中のすべてのお客様が影響を受ける可能性があります。ハイブリッド構成を採用している場合、または Microsoft Federation Gateway を信頼ブローカーとして使用して 2 つのオンプレミス組織間で空き時間情報を共有している場合は、対応を行っていただく必要があります。

この変更が行われる時期

この変更は、2014 年 9 月 23 日に実施されることが予定されています。サービス中断を回避するには、それよりも前に対応を行っていただく必要があります。

対応を行わなかった場合に発生する問題

対応を行わなかった場合、Microsoft Federation Gateway に依存するサービスをご利用いただけなくなります。たとえば以下のような問題が発生することが考えられます。

• クラウドのユーザーとオンプレミスのユーザーが互いに相手側の空き時間情報を参照できなくなる。
• ハイブリッド構成でメール ヒントが機能しなくなる。
• 組織上の関係が設定されている組織間で、クロスプレミスの空き時間情報が利用できなくなる。
  

行っていただく必要がある対応

Exchange Server 2013 SP1 以降をご利用の場合は、対応を行っていただく必要はありません。これは、Exchange 2013 SP1 の共通タスクとして自動的に対応が実行されるためです。最新バージョンの Exchange Server 2013 をインストールいただくと、これが自動化タスクとして処理されるようになります。

Update: Windows Server 2008 を Exchange 2013とご利用の場合は, 自動更新機能が利用できません。 (Windows Server 2012をご利用の場合は利用可能). メタデータの更新方法は下記の方法に従ってください。

Exchange 2013 SP1 以降をご利用いただいていない場合は、スケジュールされたタスクを作成することで、フェデレーションの信頼を最新の状態に保つことができます。Exchange Server 上で次のコマンドを実行すると、更新プロセスを定期的に実行するためのスケジュールされたタスクを作成できます。フェデレーションの信頼を常に最新の状態に保つには、この方法をお勧めします。これにより、今後のメタデータの変更の際にも悪影響を受ける心配がなくなります。

 Schtasks /create /sc Daily /tn FedRefresh /tr "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata" /ru System

スケジュールされたタスクを使用しない場合は、このコマンドを随時手動で実行してメタデータを更新することが可能です。ただし、手動での更新を選択した場合でも、少なくとも月 1 回はフェデレーション情報を更新していただくことをお勧めします。

 Get-Federationtrust | Set-FederationTrust –RefreshMetadata

Jim Lucey

こんにちは、Exchange サポートの山木です。

SSL 3.0 の脆弱性に関する問題を受けて、最近 SSL 3.0 の無効化を行った場合の Exchange サーバーへの影響についてお問合せが増えています。そこで本日は SSL 3.0 を無効化した場合の Exchange の影響についてお話させて頂ければと思います。

下記ブログにも記載されております通り、SSL 3.0 を無効化することによる Exchange 2010 への影響はございません。

Exchange 2010 は TLS による通信の暗号化をサポートしているため、Exchange 2010 がインストールされた Windows マシンで SSL 3.0 を無効化しても、引き続き TLS による通信の暗号化を行うことができます。よって、Outlook や TLS を有効化 (SSL 3.0 を無効化) した IE からの OWA 接続などについては、Exchange サーバーにて別途設定変更などを行う必要はなく、これまで通り Exchange へ接続することが可能です。

- 参考情報
Title : Vulnerability in SSL 3.0 – Poodle attack and Exchange 2010 or Exchange 2013
URL : http://blogs.technet.com/b/samdrey/archive/2014/10/17/vulnerability-in-ssl-3-0-poodle-attack-and-exchange-2010-or-exchange-2013.aspx

また、クライアント側の SSL 3.0 無効化の対処法につきましては下記参考情報を併せてご参照下さい。参考までに IE にて SSL 3.0 を無効化して TLS を有効化する場合は下記のような設定となります。

- 参考情報
Title : マイクロソフト セキュリティ アドバイザリ 3009008
URL : https://technet.microsoft.com/ja-jp/library/security/3009008.aspx