Office365を導入する目的として最も多い要因は、メールシステムの更改かと思います。

各種ドキュメント、書籍や事例などによってかなり多くの情報が得られるようになってきましたが、Office365のExchange Onlineのベースとしているソフトウェア「Exchange Server」は、インターネット上で利用されてきているSendmailやPostfixなどのMTA（メール転送エージェント）と比較して、特徴的な実装となっているところがあります。

ここでは、Office365を導入する前に有益な情報となるよう、一般的なメールシステムと比較してのExchangeの特徴についていくつか記載をさせて頂きたいと思います。

①From詐称ができない

• Exchangeでは、各ユーザーは標準で「自身のプライマリアドレスでメールを送信する権限」を有しています
• 1つのユーザーに対しては、1つの「プライマリメールアドレス」と複数の「セカンダリメールアドレス」を割り当て、メールを受信することができます
• この為、他のユーザーや配布グループなどのアドレスをFromアドレスとしてメールを送信しようとすると、「権限がない」と弾かれます
• 送信者アクセス権（SendAs）という権限を割り当てる事により、Fromアドレスを変更してメールが送信できます。（内部では、そのFromのアドレスのメールボックス経由でメールが送信されるように処理がされます。）
• SendAsは、SMTPプロトコルを使ってメールを送信する場合には利用できません。

②MessageIDが重複するメールは1通しかメールボックスに届かない

• Exchangeでは、短時間（1時間以内）に同一MessageIDであるメールが同じメールボックスに到着した場合、後から到着したメールを重複として破棄します。
• これにより、Toを本人としCcをメーリングリストとして送信されたメールは、Toで直接配送されてきたメールのみ受信され、Ccで展開された後のメールは受信されません。
• メーリングリストでSubjectに通番を付けているような場合、その番号のメールのみ欠落して見えるなどの症状となります。

③メールアドレスの表示名がサーバ側で自動的に書き換えられる

• Exchangeでは、FromやToなどの欄に表示される名前をグローバルアドレス帳の情報によって解決します。
• この為、従来は自身でアドレス帳登録した名前、”舞黒 部長”<maikuro@contoso.com>などを宛先として送付できたのが、自動的に舞黒太郎<maikuro@contoso.com>などの全社的なグローバルアドレス帳に登録されている名前（通常、フルネームをベースとしている値）に自動的に書き換えられて送信されます。
• デフォルトの設定だと、日本語の表記のまま海外のユーザーにも配送されてしまいます。特定ドメイン、もしくは全体に対して明示的に表示名をアルファベット表記に変更できます。変更方法はこちら。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

④MIMEエンコードはExchange外部に出る際に実施される

• Exchange内部では、SMTPで通常利用されるエンコードではなく独自の形式でメールが送受信されます。
• SMTP送信時に必要となるMIMEエンコードなどはクライアントでは必要なく、OutlookやOWAはエンコード処理を行いません。
• エンコードのオーバーヘッド（約3-40%）が必要無い分、SMTPよりネットワークトラフィックは軽くなります。
• Office365は25MBのメールサイズが上限ですが、これはエンコード前の値を仕様として表記した物であり、内部では35MBの容量が設定されています。この為、30MBの添付ファイルはOutlookでは送信できるが、Thunderbirdでは送信できないという事象が発生します。（勿論、外部に送信する際にはエンコードされるので35MBの上限値に引っかかりますが）
• MIMEエンコードされるのは、Exchangeから外部に送信される際に相手先のサーバを自動判定してエンコードが実施されます。
• 外部サーバがExchangeと判定された場合、TNEF形式でメールがエンコードされます。外部連絡先に登録したユーザーにwinmail.datの添付ファイルだけ付いた空メールが届くという事象のはこの自動判定に起因する物です。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

⑤Exchange内部ではMXレコードを参照せずに配信する

• Exchange内部では、他のMTAで権限のあるドメイン（MyDestination）と設定した場合と同様、内部ドメインはDNSを参照しません。
• DNSの代わりに、ActiveDirectoryの中のProxyAddressesの値（プライマリメールアドレス、セカンダリメールアドレス）で一致する物を検索し、有った場合はそのユーザーのメールボックスへの配送を行います。
• 内部ドメインであるが、そのアドレスがADに無かった場合の挙動は、そのドメインの種別によって異なります
  • 「ホスト」 宛先不明としてメールを破棄し、配送不能メール（NDR）を送信元に送ります
  • 「中継」 FOPEからMXレコードを参照して外部に配送します

⑥キャッチオールアドレスは作成できない

• 存在しない宛先宛てのメールを全て特定の受信者（例えば管理者）に送信することはできません。
• オンプレミスのExchange 2010 Serverであれば、キャッチオールメールボックスという物を作成することによって近い機能を実装できますが、Office365では提供されていません。

⑦配布グループは通常メール以外は受け取れない

• 配布グループは仕様上通常配送のメールのみ受け取ることができ、NDRなどは展開することができません。
• この為、配布グループ宛に送信したメールが展開された後に、例えばメンバーの退職、メールボックス溢れなどが有った場合のエラーメールなどは「破棄する」「配布グループの代表所有者に返信」「送信元に返信」の3つの処理しかできず、通常のメーリングリストなどで良く見られる「管理者グループ宛に返信する」という形式は利用できません。（管理者グループを作成したとしても、エラーメールを展開できないからです）

⑧メール以外の情報もメールボックスに格納されている

• 例えば、主要な機能である予定表、タスク、個人の連絡先などはメールボックスの中の特殊フォルダとして管理されています。
• その他、受信トレイルールや宛先情報のキャッシュなど、細かい設定情報などもメールボックス上に存在します。
• これらの情報は、通常のPOP/IMAPなどのクライアントからはアクセスできない為、それらのクライアントでは機能自体を利用する事ができません。
• 「迷惑メール」フォルダに関しては通常メールボックスとしてIMAPからアクセスできますが、POPは受信トレイにしかアクセスできません。この為、POPを常用する場合は定期的にOWAでアクセスして、迷惑メールフォルダの内容を確認（間違えてspamと判定されている物は無いかなど）するという運用が必要になります。

⑨メール送信処理はサーバー（メールボックス）で実施され、送信履歴も残る

• メールをクライアントが送信しようとした場合、その処理は直接送信ではなく「送信フォルダに送信したいメッセージを作成する」という処理になります。
• サーバ側では、定期的に各送信フォルダからメールをピックアップし、送信処理を行います。送信が完了すると、そのアイテムを送信済みフォルダに移動します。
• この為、Exchangeでは受信メールだけではなく、受信メールに関しても全てExchangeサーバ側で保管されています。この仕組みをベースとして訴訟ホールドなどの機能で監査対応などを実施します。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。この為、Outlook/OWA以外を利用する場合、一部（内→外）のメールの監査ができない可能性がございます。

⑩送ったメールのリボーク（取り消し）ができる

• 送信済みメールを取り消したり置き換えたりすることができます。
• 例えば、送り先を間違えた場合や添付ファイルを忘れた場合など、あわてずにOutlookクライアントから送信済みアイテムを開き、「メッセージの取り消し」を行うと、自動的にアイテムを削除したり置き換えたりしてくれます。
• 相手先が未開封（もしくはPOPなどの場合は未ダウンロード）だった場合に限ります。

いかがでしたでしょうか？

知らない機能であったり、移行してみて少し挙動が変だなと思うことがあるような要因になるようなものを集めてみましたが、他にも「こんな事あるよ」とか「こうなってるのはどうなの？」とか有りましたら教えて頂けると幸いです。

Exchange Onlineは、Exchange Server 2010をベースに構成されております。この為、基本的な機能はオンプレミスのExchangeと同じですが、細かい使い勝手で差分があります。

クラウドサービスであるOffice365を使う上では、導入前にその差分について十分検討し、Fit&Gapを行っていくことが重要です。機能一覧上は一見オンプレミスと同じだし、価格も安いので…というだけで導入を決めてしまうとあまり良い結果を生まないと思います。

ここでは、構築運用実績のあるExchangeエンジニアの立場として、オンプレミスのExchange 2010と比較した場合のクラウド（Office 365）のExchange Onlineについて、いくつかのポイントに絞って考えてみたいと思います。

詳細はExchange Onlineサービス詳細の巻末の機能比較表をご覧下さい。

①インターネット上にあるパブリッククラウドサービスである

• インターネット接続が必要
  • クライアントから直接インターネット上の名前解決が必要
  • クライアントからインターネットへのIPルーティングが必要
• 内部にメールサーバを置く場合に比べ、回線の帯域がより多く必要
  • 内部メールの送受信も経由する為
  • 1通のメールに複数の宛先や配布グループが含まれている場合の、展開後の個々での受信処理
• 通常はPIPからGIPへのNAT（NAPT）が必要
  • TCPポートの割り当て数に制限が有るので、推奨は2000クライアントごとに1GIP
• URLは他のテナントと共有
  • 他テナントのExchange Onlineとドメイン上は区別が付かない。「インターネット上のWebメールサービスは利用不可」などのコンテンツフィルタルール不可

②シェアドサービスであり、設定変更（カスタマイズ）できる範囲に制限がある

• アドレス帳のカスタマイズ
  • 階層型アドレス帳の利用不可
  • 分割やフィルタ不可（部門毎のアドレス帳の作成や、グループ企業利用の際の公開範囲を自社のみへの限定など）
• 送受信コネクタのカスタマイズ
  • 匿名アクセスを許可した受信コネクタ（認証無しのSMTP接続が可能）の作成不可
  • システムメールの送信は認証無しでは不可（内部向けのみの場合は送信先をFOPEのアドレスにして外部メール扱いで対処するなど可能）
• パブリックフォルダ
  • パブリックフォルダ利用不可
  • Outlook2003からのMAPI接続不可（予定表などの機能利用不可）
• 閾値制御
  • 公平制御の為、送信速度や宛先数などに上限値の制限が掛かっている（一部SRにて緩和可能）
  • NW帯域がLANに比べると遅い。特にGB単位のデータ移行やコピーは経験上2GB/時間程度を目安にして、気長にやった方がいい。
• ログファイル
  • メッセージ追跡ログやパフォーマンスモニタなど、サーバの生ログデータを利用した、メール関連の統計情報（送受信通数、サイズ、トラフィック量、内・外区分など）が取得できない
  • メッセージ追跡ログの取得期間の延長ができない
• セキュリティ
  • 送信元のIPベースの制限不可
  • 別AD組織なので、シングルサインオンするにはADFSが必要
  • 証明書ベースの認証不可

③クラウドサービスであり、オンライン側で運用され、随時更新される

• メジャーバージョン含めて、バージョンアップされる
  • メンテナンス事前告知は原則有る。仕様変更は全テナント完了後の場合が多い
  • バージョンアップなので基本的に改善
  • 変更したくない場合でも原則実施される
  • 要件に合わせてクライアントも随時バージョンアップする必要がある。場合によっては新規購入を含めた処理が必要。
• コミュニケーション
  • メンテナンスは基本的に一方的な通知によって行われる。サービス断がある場合でも自社で定めたメンテナンスウィンドウなどの考慮は行われない
  • 故障発生時も同じく基本的にポータルにて通知される。故障問い合わせは受け付けて貰えるが、実際のデータセンタでの対応状況などの確認は困難
  • 電話での受付はあるが、オンサイトでの対応は原則不可
• 随時サービス仕様が変わる
  • 接続先サーバーのURL、IPアドレスなどは仕様変更や収容変更、増設などによって随時変更される
  • IP情報は公開される。比較的頻繁に追加され、IPベースのフィルタ制御は推奨されていない

簡単に並べるとこんな所でしょうか？

これだけ書くと、デメリットばかり並べているように見えますが、これだけ多くのお客様がOffice365を導入しているという事例などを見ますと、代替案などを検討して上手く落としどころを作ったり、サービスの方に合わせて自社の運用を変えたり、割り切ったり…という決断をされたお客様は結構多いということなのではないでしょうか。