PST のパスワードとセキュリティ

Outlook には、PST にパスワードをかける機能があります。
昨今の情報漏洩問題などに備え、セキュリティを高めるという意味ですべての PST にパスワードをかけて運用されているという方もいると思います。

しかし、残念ながら、PST のパスワードでセキュリティはほとんど強化されません。
これについては、マイクロソフトの技術情報でも以下の通り明記されています。

4.2 Strength of PST Password

The PST Password, which is stored as a property value in the message store, is a superficial mechanism that requires the client implementation to enforce the stored password. Because the password itself is not used as a key to the encoding and decoding cipher algorithms, it does not provide any security benefit to preventing the PST data to be read by unauthorized parties.

Moreover, the password is stored as a CRC-32 hash of the original password string, which is prone to collisions and is relatively weak against a brute-force approach.

https://msdn.microsoft.com/en-us/library/ff387042(v=office.12).aspx より

セキュリティに役立たない理由は二つあります。

一つ目は、パスワード自体が PST の暗号化に関わっていないということです。
一般にパスワードがかかったファイルは、そのパスワードをキーとした暗号化が行われており、パスワードがなければファイルのデータを読み取ることができないようになっています。
しかし、PST の場合、そもそも一般的な意味での暗号化 (※1) はされていません。
そのため、パスワードがわからなかったとしても、PST のデータ フォーマット (※2) を理解していれば、データの解読ができます。

二つ目は、パスワード自体の暗号化が弱いということです。
PST のパスワードは、元のパスワードをもとに CRC-32 というアルゴリズムで生成したハッシュコードを PST に格納し、ユーザーが入力したパスワードのハッシュと照合して認証するという仕組みになっています。
しかし、CRC-32 では正しい文字列以外でも同じハッシュ コードになる文字データの組み合わせが存在し、総当たり攻撃という手法で簡単に突破できるものです。
PST の仕様が定められた 20 年前にはこの方法でもセキュリティはある程度保てていたのかもしれませんが、現在のコンピュータ環境では数秒で正しいパスワードと認識されてしまう文字列が生成可能であり、実際にサードパーティからは PST のパスワードを解読するツールがリリースされています。

したがって、例えば家庭内で子供がアクセスするのを防ぎたいというような程度のセキュリティには使用できると思いますが、企業において情報漏洩を防ぐためという目的では全く無力なものあり、そのような目的には Windows の暗号化ファイル システム (EFS) や BitLocker を使うべきでしょう。

※1: ユーザーデータについては一定のアルゴリズムで暗号化されています。しかし、キーなしの暗号化方式であり、暗号化のアルゴリズムがわかってしまえば解読できるものであるため、暗号化というより難読化と呼ぶべきものです。これについての詳細は https://msdn.microsoft.com/en-us/library/ff386520(v=office.12).aspx で説明されています。
※2: PST のデータ フォーマットは https://msdn.microsoft.com/en-us/library/ff385210(v=office.12).aspx で公開されています。

Exchange Online でやってはいけない 10 のこと

以前、Outlook でやってはいけない 10 のことという記事で Outlook を使用するうえで問題が発生しうる使用方法について説明しましたが、Exchange Online 環境ではクラウド サービスという性質上、オンプレでは問題なかったものの、クラウドでは注意が必要な使い方というものがあります。
今回はそのような使い方などについて説明します。

1. オンライン モードで使用する

クライアント端末の紛失や盗難に備え、クライアント上に情報を保持させないようキャッシュ モードではなくオンライン モードで Outlook を使用するというのはよくある使い方です。
しかし、Exchange Online ではキャッシュ モードが強く推奨されています。
これは、インターネットの通信遅延によるものです。
Exchange Online への接続にはインターネットが使用されるため、クライアントからサーバーへのアクセスは複数のルーターやネットワークを経由する場合があります。
そして、経由するルーターやネットワークが多くなればなるほど、少しずつパケットの遅延が累積していき、クライアントからのリクエストに対するサーバーの応答が遅くなることになります。
オンライン モードで使用している場合、アイテムの一覧表示やアイテムの表示、変更など、Outlook のほとんどすべての操作でサーバーとの通信が発生するため、それらがすべて遅くなる可能性があり、ネットワークによっては使用に耐えられない状況となる場合があります。
残念ながら、インターネットの通信遅延については改善する方法はほとんどないため、オンライン モードでパフォーマンスを改善する方法はないといってよいでしょう。
どうしてもクライアントにデータを置くことができないのであれば、Outlook をオンライン モードで使用するより Outlook on the Web (OotW) を使ったほうが良いかもしれません。

2. 最新でないバージョンで使用する

延長サポートに入っているものも含めて、現在サポートされている Office のバージョンは 2007、2010、2013、2016 とあります。
そして、現時点では Exchange Online には、現在サポートされているすべての Outlook のバージョンで接続できることが可能です。
しかし、この状況はいつまでも続くものではありません。
Outlook 2007 のサポートが終了を迎える 2017 年 10 月に、Exchange Online で RPC/HTTP での接続が終了します。
RPC/HTTP とは Exchange Online に接続するための方法のひとつで、現在は RPC/HTTP という方法と MAPI/HTTP という方法の 2 つがサポートされているのですが、2017 年 10 月 31 日に RPC/HTTP が廃止され、MAPI/HTTP に一本化されるのです。

ここで問題となるのは Outlook 2007 です。
Outlook 2010 以降では修正プログラムの適用などで MAPI/HTTP が使用可能となっていますが、Outlook 2007 には MAPI/HTTP を使用する方法が用意されていません。
そのため、10 月 31 日以降は Outlook 2007 で Exchange Online に接続することができなくなるということになります (メールの送受信だけで使うなら POP や IMAP で接続することは可能です)。

これまでは、サポートが終了するといっても自己責任で使用し続けるということはできましたが、RPC/HTTP の廃止は実質的にバージョンアップが強制されるものであり、相当のインパクトがあると考えられます。
今後も、古いバージョンで発生する問題が修正されなかったり、新しい機能が使用できないなどの不都合は出てくると考えられます。
Office 365 に限らず、クラウド環境は常に進化し続けることがメリットの一つであるため、そのメリットを享受する意味でも、最新のバージョンを使用したほうが良いでしょう。
もし、社内の都合などで特定のバージョンを使用し続けなければならないという制約があるなら、クラウドへの移行は見送ったほうが良いかもしれません。

3. Outlook の最新バージョンと他の Office 製品の古いバージョンを混在させる

上記にも関連することですが、Exchange Online への接続要件を満たすために、Office 全体のバージョン アップはせず、Outlook だけのバージョン アップを検討される方もいるようです。
しかし、Outlook と他の Office のバージョンが異なる場合、製品の連携などに制限が出ます。
例えば、Outlook と同じバージョンの Word がインストールされていない場合、Outlook のメール編集の際に Word を使用する一部の機能が使用できません。
また、Office ファイルの添付ファイル プレビューなども使用できません。
バージョン アップできない理由は様々あると思いますが、いずれはバージョン アップが必要になるのは確実であり、先送りすればそれだけ問題が増えていくと考えたほうが良いでしょう。

4. 参照権限以上で予定表を共有する

他のユーザーの予定を把握するため、予定表をグループなどで共有するというのはよくある使い方です。
しかし、参照権限以上で予定表を共有すると Exchange Online 特有の壁にぶつかる場合があります。
Outlook でほかのユーザーの予定表を開く場合、その予定表にアクセスするための個別の TCP セッションが必要となります。
問題はキャッシュ モードで [共有フォルダーをダウンロード] がオンになっている場合です。
この設定をしていると、Outlook は一度開いたほかのユーザーの予定表についても OST にキャッシュするのですが、このキャッシュ情報を常に最新にするために、Outlook の起動直後から TCP セッションを確立する動作となります。
そのため、例えば 30 個の予定表フォルダーを開いた場合、その後は常に 30 (RPC/HTTP の場合は 60) の TCP セッションを確立し、Outlook が終了するまでセッションを張り続けます。
これによりプロキシや NAT の TCP セッションが不足するという問題が生じる可能性があるのです。
これを回避するには [共有フォルダーをダウンロード] をオフにするというものが考えられますが、この設定にするとほかのユーザーの予定表表示が遅くなったり、多数のユーザーの予定表を表示する際に Outlook がハングアップする場合があります。
そのため、基本的には予定表の共有は [空き時間情報、件名、場所] という権限で行ったほうが良いでしょう。
この権限の場合、予定表フォルダーへのアクセスには個別の TCP セッションが不要となり、サーバーから一括で複数ユーザーの最新の情報を取得することが可能です。

5. オンプレと Exchange Online で同じ SMTP アドレスのメールボックスを並行運用する

オンプレから Exchange Online への移行にあたって、問題発生時の切り戻しを考えて、オンプレと Exchange Online の両方にメールボックスを用意して段階的に移行しようと考える方がいるようです。
結論から言うと、大体はうまくいきません。
まず、オンプレから Exchange Online への切り替えで、AutoDiscover の振り先だけ変えればクライアントの移行が完了する、と期待していると大幅に裏切られます。
Outlook の OST にはメールボックスの GUID というものが保持されており、この GUID は同じ SMTP アドレスを使っても全く違ったものが設定されます。
そして、Outlook は接続したメールボックスの GUID が OST に保存されている GUID と異なる場合、「一時メールボックスに接続した」と判断します。
その結果、以下のようなダイアログが表示されます。

「メールボックスは、一時的に Microsoft Exchange サーバーで移動されています。一時メールボックスは存在しますが、以前のデータの一部が含まれていない可能性があります。

一時メールボックスに接続するか、以前のデータをすべて使用してオフラインで作業することができます。以前のデータを使用する場合は、電子メール メッセージの送受信はできません。」

このメッセージの通り、この状態になるとオフラインで移行前のメールボックスのメールを参照するか、オンライン モードで Exchange Online のメールボックスにアクセスするかの二択になり、移行前のメールを自動的に Exchange Online に移動する、というようなこともできません。
さらに問題なのは、プロファイルがこの状態になると起動時に必ず上記のメッセージが表示されるようになり、AutoDiscover の振り先をオンプレに戻しても解消できないという点です。
これを解消するにはプロファイルの再作成しか方法はありません。

また、プロファイルの作り直しをするつもりでも、うまく AutoDiscover を制御できなければ想定外の情報を取得して上記の一時メールボックスの状態になる可能性があるので、「Exchange Online 移行のパフォーマンスとベスト プラクティス」にあるような方法での移行をお勧めします。

6. インターネット接続の帯域幅を増やさずに移行する

オンプレミスで Exchange サーバーを運用していたものを Exchange Online に移行する場合、インターネットへのトラフィックは増えることが予想されます。
ただ、どの程度増えるのかという予測は非常に難しいものです。
単純なメールの送受信量だけでなく、予定表などの共有状況などにより、トラフィックが大幅に増える可能性もあります。
そのため、現在のインターネット接続の帯域幅の使用量がすでに飽和状態に近いのであれば、帯域幅を増やす必要があるでしょう。
帯域幅の増やさずに、Exchange Online へのトラフィックを制限しようとしても、効果的な方法は実際のところありません。
なぜなら、そもそも無駄なトラフィックを発生させるような設計にはなっていないためです。
現時点で帯域幅に多少の余裕があっても、使用状況によってはすぐにひっ迫する可能性もあるので、インターネット接続の増速がどのくらいの期間と費用でできるのかを、移行前にあらかじめ見積もっておくと安心です。
もし、増速が難しいような状況なのであれば、Exchange Online への移行は見送ったほうが良いかもしれません。

7. 自社で IT インフラの要員を確保しない

クラウド サービスへの接続で問題が発生する場合、原因としては大きく分けて以下のようなものが考えられます。

    1) クラウド サービスのサイト内のサーバーやネットワークの問題
    2) クラウド サービスと自社ネットワークの間のインターネットの問題
    3) 自社ネットワーク内のルーターやプロキシなどネットワークの問題
    4) クライアントの問題

このうち、クラウド サービスのサポートに問い合わせて対応してもらえるのは、1) と 4) です (サービスによっては 1)  だけの場合もあります)。
しかし、2) や 3) についてはクラウド サービスが用意するものではないため、サポートの対応には限界があります。
クラウドにしてしまえば自社の IT 要員が不要、と勘違いしていると、いざ 2) や 3) で問題が生じたときに、誰も対応できないという事態に陥ります。
そのため、クラウド サービスを使う場合でも、自社の IT インフラをサポートできる要員を確保するべきです。

8. Outlook から IMAP で接続する

Outlook には IMAP でサーバーに接続する機能があります。
また、Exchange Online には IMAP でクライアントからの接続を受ける機能があります。
したがって、Outlook から Exchange Online に IMAP で接続することは技術的には可能であり、サポート対象外ということもありません。
そのため、以下のような理由で Exchange Online に IMAP で Outlook から接続することを検討される方もいるようです。

  • 古いバージョンの Outlook で接続したい
  • オンプレや別サービスと同じ SMTP アドレスを使いたい

ただ、本来は Outlook や Exchange Online の IMAP 機能はサードパーティ製のメール サーバー/クライアントと接続するためのものであるため、IMAP を使用した場合には Exchange や Outlook 固有の機能が使えず、メリットがほとんどありません。
また、このような使い方はレアなケースであるため、想定外の不具合に遭遇する可能性が高いと考えられます。
したがって、IMAP で接続するくらいなら、OotW を使ったほうがより Exchange Online のメリットを享受できるといえます。

9. 原因追及を要求する

クラウド サービスではオンプレとは比べ物にならない台数のサーバーが常時稼働しています。
そして、一定の割合でハードディスクやネットワーク機器の物理的な故障などが発生することが想定されます。
そのため、語弊を恐れず言えば、クラウド サービスでは常に何らかのトラブルが生じていると考えられます。
もちろん、そのようなハードウェアの障害が発生しても、ユーザーに影響を与えないような構成となっているわけですが、それでも予期せぬトラブルというものは発生するものです。
オンプレ環境の場合、サーバーのダウンや障害などが発生した際には、原因追及や再発防止などの対策をとると思いますが、クラウドで同じレベルの原因追及や再発防止策の要求は極めて困難です。
というのも、車に例えるなら、オンプレは自家用車のようなものであり、クラウドというのは乗り合いバスのようなものだからです。

オンプレ環境は、ハードウェアは自前で持つことにより、トラブル発生時の対応や調査も自分で行う必要があります (SIer にすべて任せるという手もありますが)。
その代わり、いつまでも古いバージョンを使い続けたり、特殊な使い方をすることもできます。

一方、クラウド環境は多数のユーザーとハードウェアやソフトウェアを共有するものであり、基本的には自動的に最新のバージョンに更新され、使用方法の自由度はオンプレと比べて制限があります。
その代わり、メンテナンスはクラウド サービスに任せることができます。

したがって、クラウド サービスを使うに当たっては、サービス提供者を信頼し、トラブルが生じても原因追及や再発防止も含めて一任することにしてしまうのが良いと思います。
トラブルのたびに原因追及や再発防止策が提示されなければ不安ということは、いわば信頼できないクラウド サービスを使用しているということなので、そのようなサービスに自社のデータを預けるべきではないでしょう。

10. エンド ユーザーの要求をすべて実現しようとする

前述の通り、クラウド サービスではオンプレに比べて設定や拡張性に制限があり、エンド ユーザーの要求をすべて実現しようとすると、様々な障害に遭遇する可能性があります。
例えばメールの送受信数制限のようなサービス全体に影響を与えうるものについては、クラウドとオンプレでは設定できる範囲が異なり、たとえ一時的であっても、その制限を超えるような方法は用意されていません。
そのような状況で要求を実現しようとしても、特別対応される可能性はほとんどないでしょう。
また、クラウド サービスではある日突然 (実際には事前にアナウンスされていることがほとんどなのですが) 新機能がリリースされ、メニューが追加されたり、反対に機能が削除されたりする場合があります。
それについて機能を増やしたくないとか、削除されると困るというようなことを言っても、対応される可能性は低いといえます。
したがって、クラウド サービスを使うに当たっては、エンド ユーザーの様々な要求 (ローカルにデータを置きたくない、バージョンアップしたくない、全員の予定表の詳細を見たいなど) をすべて実現しようとせず、基本的にあるがままを受け入れるというスタンスで使うほうが良いでしょう。
もし、エンドユーザーを説得する自信がないのであれば、クラウドへの移行は見送ったほうが良いかもしれません。

まとめ

Exchange Online について、様々な制限を書いてしまったため、クラウドよりオンプレのほうが良いと思われる方もいるかもしれません。
しかし、オンプレでは使用できない最新の機能が Exchange Online なら使用可能であり、サーバーのメンテナンスからも解放されるという大きなメリットがあります。
いずれにせよ、クラウドとオンプレで全く同じ運用や使い方はできないと認識し、クラウドの特性を生かした使い方をすることで、より安定して快適な運用ができるようになるでしょう。

Outlook の「既定のフォルダー」の名前を変更する

コメントにて以下のご要望をいただきました。


Windows8.1 Outlook2013にて、ぷららへIMAP接続でメールを使用しています。
Outlook2010までは下記ページのSTEP 12図のように「送信済みアイテム」と「Sent」フォルダが重複して作成されても、STEP 16図のようにインターネット電子メール設定で指定すれば問題なかったのですが、Outlook2013のにはインターネット電子メール設定に、この「送信済みアイテム」と「削除済みアイテム」タブがありません。また「送信済みアイテム – Sent」と「削除済みアイテム – Trash」ペアの他に、「迷惑メール – Junk」も重複してフォルダが作成されてしまいます。これら重複して作成されてしまうIMAPフォルダをマクロで一致させることは出来ないでしょうか?可能でしたら、ぜひともお願い致します。

Outlook 2010 新規設定方法(IMAP)
http://support.eonet.jp/setup/mail/imap/win/ol2010_setup_imap.html


残念ながら、Outlook では既定で作成される「受信トレイ」や「送信済みアイテム」、「削除済みアイテム」のようなフォルダーは「既定のフォルダー」という特別なフォルダーとして扱われており、このフォルダーをマクロで別のフォルダーに変更したり、フォルダーの名前を変えたりというようなことはできません。
また、「既定のフォルダー」については、Outlook がこれらのフォルダーを作成した際に、そのフォルダーのエントリ ID を PST やメールボックスのプロパティとして保存しており、この情報を変更することもマクロではできません。

しかし、MFCMAPI というツールを使うと、既定のフォルダーであっても名前を変更することが可能です。
今回のように IMAP サーバーと重複するフォルダーに名前を変更する場合の手順は以下の通りになります。

  1. http://mfcmapi.codeplex.com にアクセスし、画面右の [download] ボタンをクリックして zip ファイルをダウンロードします。
  2. ダウンロードした zip ファイルを展開し、MFCMAPI.EXE を取り出します。
  3. MFCMAPI.EXE を実行します。
  4. 起動画面で [OK] をクリックします。
  5. [Session] メニューの [Logon…] をクリックします。
  6. [プロファイルの選択] ウィンドウで IMAP 接続のプロファイルを選択し、[OK] をクリックします。
  7. [Display Name] が電子メール アドレスとなっているエントリをダブルクリックします。
  8. [ルート – メールボックス]-[IPM_SUBTREE] と展開します。
  9. [IPM_SUBTREE] の下の [Sent] をクリックし、2 秒ほど待ってから再度クリックします。
    すると、Sent が反転し、文字入力状態となります。
  10. ”Sent.bak” と入力し、Enter キーを押します。
  11. [IPM_SUBTREE] の下の [送信済みアイテム] をクリックし、2 秒ほど待ってから再度クリックします。
  12. ”Sent” と入力し、Enter キーを押します。

これにより、Outlook の既定の「送信済みアイテム」フォルダーの名前が、IMAP サーバーと同じ「Sent」に変更されます。
IMAP 接続ではフォルダーは名前でのみ識別されるので、このように設定した後で Outlook を起動すると、サーバー上の「Sent」フォルダーのメールが Outlook で既定の送信済みアイテム フォルダーとして認識されている「Sent」フォルダーにダウンロードされるようになります。

「削除済みアイテム – Trash」や「迷惑メール – Junk」についても上記と同様に名前を変更することで、重複を解消することができるでしょう。
なお、.bak を付けた元のフォルダーについては、同期が正しくできていることを確認した後で削除しても構いません。

Exchange 環境における電子メール アドレス = LegacyExchangeDN

一般に、電子メールアドレスというと、"xxxx@example.com" のような SMTP アドレスを意味します。
しかし、Exchange 環境の Outlook においては、以下のようなフォーマットの文字列がメールアドレスとなります。

  /o=組織名/ou=管理グループ/cn=Recipients/cn=名前またはエイリアス

これは Active Directory では LegacyExchangeDN という属性で保持されているもので、X.500 という形式のアドレス文字列となります。
なぜ SMTP アドレスではなく、このような文字列がアドレス文字列として使用されているかについては、Exchange の歴史的な背景に理由があります。

Exchange Server の最初のバージョンは 4.0 であり、このバージョンで Exchange サーバーでのメールの送受信は X.400 という規約に基づいて行われていました。
X.400 とは、ITU-T (International Telecommunication Union Telecommunication Standardization Sector) という標準化団体で策定された電子メールについての標準であり、Exchange サーバーはその時点でのオープンな標準に適合するよう X.400 をベースとしたものとなっていました。
また、アドレス帳などをつかさどるディレクトリ サービスについても同様に標準規格である X.500 をベースとしたものとなっており、この規約の文字列が Outlook においては Exchange サーバーの受信者の電子メールアドレスとして使用されていました。
さらに、このバージョンではインターネットのメールはオプション扱いであり、SMTP アドレスを持たない Exchange 受信者が存在する状態でもありました。

やがて、インターネットの普及とともに SMTP が世界的な電子メールの標準になると、Exchange Server も 2003 から SMTP をベースとしてメールの送受信を行うようになりましたが、互換性のため X.500 形式のアドレスは現在でも Outlook での Exchange 受信者のアドレスとして使用されています。名前こそ LegacyExchangeDN ですが、現役で使用されているアドレスなのです。

したがって、Exchange 環境下では LegacyExchangeDN をむやみに変更したり、再利用をしてはいけません。
たとえば、UserA と UserB が同じ LegacyExchangeDN を持っていた場合、Outlook から見るとこの 2 人のユーザーは同一アドレスとなります。そのため、UserA に送るつもりが UserB に送られるというような現象が発生する可能性があり、誤送信の原因になります。

[mailto リンクで UTF-8 を使う] と Outlook

Internet Explorer 7.0 以降には [mailto リンクで UTF-8 を使う] というオプションがあります。
この設定とメールクライアント、および mailto リンクの指定方法の組み合わせによっては、件名や本文で文字化けが発生します。
以下では IE7 の挙動がどのように変わるかと、その結果 Outlook をはじめとするマイクロソフトのメール クライアントでどのような動作が行われるかについてまとめました。

Internet Explorer 6.0 以前について

HTML 中に mailto が出現する場合、FORM で指定する場合と HREF で指定する場合があり、HREF で指定する場合はさらに全角文字を事前にエンコードする場合とそうでない場合があります。それぞれについての動作は以下の通りです。

1. フォームの ACTION を mailto: とし、Subject および Body をフォームのパラメータとして送信した場合

Subject や Body の DBCS は、HTML で指定されている文字コードで % エンコードされ、ShellExecuteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページのフォームで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

一方 UTF-8 で記述されたページのフォームで同様のパラメータを指定すると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

2. HTML 中の HREF タグで mailto のリンクの Subject および Body の全角文字があらかじめ % エンコードされている場合

HTML で指定されている文字コードに関わらず、指定された文字列がそのままメールソフトに渡されます。
例えば、下記の文字列は全角文字を Shift-JIS のコードにより % エンコードしたものですが、UTF-8 が指定されている HTML にこのようなリンクがあっても、この文字列のままメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

3. HTML 中の HREF タグで mailto のリンクの Subject および Body に全角文字を指定した場合

HTML で指定されている文字コードのまま、ShellExecutteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページの mailto リンクで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列が Shift-JIS の文字列としてメール ソフトに渡されます。

  mailto:test@example.com?subject=日本語件名&body=日本語本文

一方、UTF-8 で記述されたページの mailto リンクで同様の文字列を指定した場合、上記の文字列がエンコードされず、UTF-8 のバイト文字列としてメールソフトに渡されます。

Internet Explorer 7.0 以降について

Internet Explorer 7.0 以降では [mailto リンクで UTF-8 を使う] の設定がありますが、これをオフにした場合は Internet Explorer 6.0 以前と同様の動作となります。
また、オンにした場合でも、上記の 1. および 2. の動作は変わりません。
そして、3. の HREF タグの mailto の Subject および Body に全角文字を指定した場合に、以下のような動作をします。

  1. 文字列を HTML で指定された文字コード (または自動認識されたページの文字コード) により Unicode に変換します。
  2. Unicode 文字列を UTF-8 とし、% エンコードを行います。

そのため、 Subject を「日本語件名」、Body を「日本語本文」とすると、HTML の文字コード指定に関わらず、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

Outlook 2010/2007 について

Outlook 2010/2007 は Internet Explorer の [mailto リンクで UTF-8 を使う] の設定により動作が変わります。Outlook 2010/2007 にも [ツール]-[オプション]-[メール形式]-[文字設定オプション] に [mailto: プロトコルで UTF-8 をサポートする] がありますが、どちらのオプションも設定されるレジストリは同じ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Protocols\Mailto\UTF8Encoding になります。そのため、このオプションをオンにすると自動的に Internet Explorer の [mailto リンクで UTF-8 を使う] がオンになります。
[mailto リンクで UTF-8 を使う] がオンである場合、mailto のリンクは Internet Explorer で UTF-8 による % エンコードが行われていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、UTF-8 の文字列として取得します。
その結果、ShellExecute やショートカットを使い、Internet Explorer を経由せずに Subject や Body に Shift-JIS の全角文字を指定した場合、文字化けが発生します。
一方、[mailto リンクで UTF-8 を使う] がオフである場合、mailto のリンクは Windows の既定のコードページによりエンコードされていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、日本語環境では Shift-JIS の文字列として取得します。

Windows メールについて

Windows メールでは Internet Explorer の [mailto リンクで UTF-8 を使う] の設定によって動作が変わることはありません。
mailto リンクで指定された文字列をデコードした後、パラメータごとに処理します。
そして、件名については UTF-8 が使用されている場合でも正しく識別できますが、本文については文字化けが発生します。

Outlook 2003 以前、および Outlook Express について

Outlook 2003 以前、および Outlook Express が開発された際には、[mailto リンクで UTF-8 を使う] というオプションは存在していません。したがって、mailto に指定された文字列については、常に Shift-JIS として解釈されます。
その結果、以下の状況では文字化けが発生します。
1. UTF-8 で指定されたページにおいて、フォームにより全角文字が送信される場合
2. [mailto リンクで UTF-8 を使う] がオンにされた状態で、HTML の HREF で mailto に全角文字が指定された場合

まとめ

上記の動作をすべてまとめると以下のようになります。

Internet Explorer 6 以前、または [mailto リンクで UTF-8 を使う] がオフである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

※ UTF-8 の文字がエンコードされずに指定された場合、UTF-8 の 3 バイト目の文字が DBCS の 1 バイト目と解釈され、パラメータの連結を意味する & が正しく識別できなくなることがあります。そのような場合には、順序によって本文または件名が空白となります。

・ShellExecute 直接指定

すべてのクライアントで OK
※ ファイル名を指定して実行やショートカットなどで mailto リンクに全角文字を指定した場合も ShellExecute 直接指定と同様です。

[mailto リンクで UTF-8 を使う] がオンである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
NG
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
OK
NG
NG

・ShellExecute 直接指定

Outlook 2010/2007 は NG、他は OK

IMAP のストアが既定のデータ ストアに設定できない理由

Outlook で IMAP サーバーを使用すると、フォルダのツリー表示には [個人用フォルダ] のほかに IMAP アカウントのメールアドレスをルートとするフォルダ階層が作成されます。どちらにも受信トレイがあるため、一本化したいと思っても、個人用フォルダは既定のデータ ストアとなっていて削除できず、IMAP アカウントのツリーを既定のデータ ストアにすることができません。

このようなことが起こるのは、IMAP アカウントのツリーとして表示される IMAP ストアに制限があるためです。

IMAP というプロトコルは、基本的にはサーバー上にメールを保持し、クライアントが必要に応じてサーバー上のメールを参照するという動作になります。
そして、Outlook で表示される IMAP アカウントのフォルダは、IMAP サーバー上のメールデータのキャッシュになり、メール以外のデータを置くことができません。
一方、Outlook としては既定のデータ ファイルにメールだけでなく予定や連絡先など様々なデータを保存する必要があります。
IMAP サーバーは予定や連絡先を保存することができないため、既定のデータ ファイルとして設定できないのです。

パブリック フォルダに保存したファイルで競合が発生する現象について

ネットワーク ドライブなどの共有フォルダに Word や Excel のファイルを保存し、それを複数のユーザーで開いた場合、後で開いたユーザーについては編集ロックがかかり、先に開いたユーザーが編集を終えるまで書き込みができません。

しかし、Exchange サーバーのパブリック フォルダに直接ファイルを投稿し、それを Outlook 経由で開いたような場合、そのファイルはロックがされず複数のユーザーが同時に編集することができてしまいます。そして、別々に変更を加えて保存すると、"競合メッセージ" が発生し、どちらか一方または両方を保存するというオプションの選択になります。
このような動作となるのは、Exchange サーバーのパブリック フォルダにはロックという機構がないためです。

Exchange サーバーにはパブリック フォルダの複製機能があり、例えば東京とニューヨークのサーバーで同じフォルダを別々のサーバーによって保持するということが可能です。このような環境でロックをかけようとすると、東京とニューヨークの両方のサーバーでロックが必要となり、ロック中にネットワークの切断が発生したような場合に解除ができない、というような現象が発生する可能性があります。
このようなことが発生しないように、Exchange サーバーではパブリック フォルダ上のアイテムやファイルをロックすることはせず、複数で同時に変更が発生した場合には競合メッセージを生成するという仕様になっています。

複数のユーザーでファイルを編集しつつ、ロックなどの機能も必要ということであれば、Windows SharePoint Service などを使ってください。