Outlook 2010 で複数の POP アカウントのメールを一つの受信トレイで管理する方法

Outlook 2010 から一つのプロファイルに複数の POP アカウントを設定した場合、既定ではアカウントごとに個人用フォルダー ファイルが作成され、それぞれの受信トレイに配信されるようになりました。この動作はメールがどのアカウントにあてて送信されたかを認識できるためと思われますが、以前のように複数アカウントでも一つの受信トレイでまとめて確認したいという方もいると思います。

アカウントの追加の際に既存の個人用フォルダーを選択することもできるのですが、すでに追加してしまって複数の受信トレイができてしまっている場合には、以下の手順で一つの受信トレイに配信するように設定可能です。(Account1 の受信トレイで Account2 のメールも受信する例)

  1. Outlook 2010 を起動します。
  2. [ファイル]-[情報]-[アカウント設定]-[アカウント設定] の順にクリックします。
  3. 配信先を変更したいアカウント (Account2) を選択し、[フォルダーの変更] をクリックします。
  4. [フォルダーの選択] で、配信先とする別のアカウント (Account1) の受信トレイを選択し、[OK] をクリックします。

なお、この手順を実行しても、すでに配信済みのメールは自動的には移動されませんので、配信済みのメールも一つの受信トレイに集約したい場合は手動でコピーしてください。

Outlook 2007 で追加された空き時間情報の権限

Exchange Server 2007 以降の環境で、Outlook 2010/2007 により予定表フォルダーのアクセス権を見ると、既定のアクセス権が [空き時間情報のみ] となります。一方、Outlook 2003 では既定のアクセス権は [なし] となっているため、Outlook 2007 以降でアクセス権が緩められたように錯覚される方もいるかもしれません。しかし、実際には Outlook 2003 の [なし] という権限は、Outlook 2007 の [空き時間情報のみ] と同じ権限になります。では、いったい何が変わったのでしょう?

Outlook 2003 では空き時間情報をパブリック フォルダーにある Schedule+ システム フォルダーから取得します。このフォルダーには空き時間情報を格納したアイテムが 1 ユーザー 1 アイテムとして保存されていますが、Exchange サーバーではアクセス権が基本的にはフォルダー単位でしか設定できず、空き時間情報のアクセス権はアイテム (ユーザー) 単位ではなくシステム単位で設定する必要があります。そのため、既定では全ユーザーにアクセス権があり、個々のユーザーでアクセス権を指定することはできませんでした。

一方、Outlook 2007 以降では Exchange Server 2007 から追加された可用性サービスから HTTP を使用して空き時間情報の取得を行います。この可用性サービスでは単に空き時間情報だけでなく、一覧表示で使用される件名や場所も取得が可能となっており、ユーザーがほかの人にどの程度まで公開するかを設定することが可能です。そのため、Outlook 2007 には [空き時間情報のみ] や [空き時間情報、件名、場所] というアクセス権が追加されています。

なお、Outlook 2007 で予定表の既定のアクセス権を [なし] にしてしまうと、Outlook 2003 との混在環境においては、ちょっとややこしいことになります。Outlook 2003 は Exchange Server 2007 の環境であってもパブリック フォルダーの空き時間情報を参照しますが、前述のとおりパブリック フォルダーに対してはアイテム単位でしかアクセス権が設定できません。そのため、Outlook 2007 で予定表の既定のアクセス権を [なし] とすると、Outlook 2007 はパブリック フォルダーへの空き時間情報の発行を行わないという動作になります。この結果、たとえ他のユーザーに空き時間情報へのアクセス権を含む参照者などの権限を与えたとしても、そもそもパブリック フォルダーに空き時間情報がないため、空き時間情報が見えなくなるという現象が発生します。
したがって、Outlook 2007 以降で予定表のアクセス権を不用意に [なし] に変更するのは避けるべきといえるでしょう。

すべてのフォルダーで閲覧ウィンドウを表示させない方法

Outlook 2010/2007 の閲覧ウィンドウは Outlook 2003 以前のバージョンに比べてはるかに安全になってるのですが、いまだにセキュリティ上の理由で無効にしたいという需要があるようです。
閲覧ウィンドウのオン・オフはビューの設定で可能ではあるものの、フォルダごとに設定する必要があるため、フォルダが多数の場合にすべてオフにするのが大変という話を聞きました。

そのような場合、Outlook.exe /nopreview として実行すると、閲覧ウィンドウを表示せずに Outlook を起動することができますので、デスクトップに以下の手順でショートカットを作り、こちらから起動することですべてのフォルダの閲覧ウィンドウをオフにしたのと同様な動作となります。

  1. デスクトップを右クリックし、[新規作成]-[ショートカット] をクリックします。
  2. [項目の場所を入力してください] に以下のように入力し、[次へ] をクリックします。

    Outlook 2010 の場合
    "C:\Program Files\Microsoft Office\Office14\Outlook.exe" /nopreview

    Outlook 2007 の場合
    "C:\Program Files\Microsoft Office\Office12\Outlook.exe" /nopreview

  3. ショートカットの名前を適切なものにし、[完了] をクリックします。

[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

追加のメールボックスと追加のアカウント

Outlook 2010 では一つのプロファイルに複数の Exchange アカウントを追加することができます。一方、Outlook 2007 以前でも、組織内の別のメールボックスにアクセス権がある場合には追加のメールボックスとして追加が可能です。
今回はこの二つの違いについて説明します。

追加のメールボックスについて

追加のメールボックスは、Exchange アカウントの [詳細設定] の [詳細設定] タブで追加したメールボックスを意味します。
この設定は他のユーザーが使用しているメールボックスに代理人としてアクセスすることを前提としています。
追加できるメールボックスは最低限メールボックスのルートフォルダーに読み取りのアクセス権限が必要となります。

追加の Exchange アカウントについて

追加の Exchange アカウントは Outlook 2010 から追加された機能で、アカウントの設定の [電子メール] タブで追加された Exchange Server のアカウントを意味します。
この設定は異なる Exchange 組織に属する自分自身のメールボックスに一つのプロファイルで同時にアクセスすることを前提としています。 そのため、フルメールボックス権限がある他のユーザーのメールボックスを追加の Exchange アカウントとして追加することはサポートされていません。
ただし、同一組織のフルメールボックス権限がないメールボックスについてユーザー名・パスワードを指定して追加する場合はサポートされるようです。

追加のメールボックスと追加の Exchange アカウントの動作の違い

追加のメールボックスと追加の Exchange アカウントの違いは、その前提が「自分自身のメールボックスかどうか」に起因します。
追加のメールボックスは自分以外がメインで使用するメールボックスとして認識されているため、以下のような動作となります。

  • 古いアイテムの整理は実行されません。
  • メッセージの取り消しは実行されません。
  • 追加のメールボックス上のフォルダーを選択してからメールを作成した場合でも、差出人は自分自身となります。
  • 差出人を追加のメールボックスのアドレスとして送信した場合でも、送信済みアイテムは自分自身の送信済みアイテムフォルダーに保存されます。(KB2459115 適用後、DelegateSentItemsStyle レジストリ設定で変更は可能。詳細は KB2181579 参照)

一方、追加の Exchange アカウントは、自分自身のメールボックスとして認識されているため、以下のような動作となります。

  • 古いアイテムの整理が実行されます。
  • メッセージの取り消しが実行されます。
  • 追加の Exchange アカウントのメールボックス上のフォルダーを選択してからメールを作成した場合には差出人は追加の Exchange アカウントとなります。
  • 差出人を追加の Exchange アカウントとして送信した場合には、送信済みアイテムは追加の Exchange アカウントの送信済みアイテムフォルダーに保存されます。

Exchange Server 2010 SP1 環境で発生する問題について

Exchange Server 2010 SP1 環境では、Auto Discover によりフルメールボックス権限のあるメールボックスが自動的に Exchange アカウントに「追加のメールボックス」として追加されます。
その後、同じメールボックスが「追加の Exchange アカウント」として追加された場合、UI の見かけ上は追加の Exchange アカウントとして表示されます。
しかし、実際には Outlook の内部で「追加のメールボックス」として取り扱われ、意図しない動作となります。
これについては、マイクロソフトのサポートページ (981245 You cannot use a manager and delegate account in the same Outlook 2010 profile) に下記の通り記載があります。

Exchange Server 2010 SP1 Auto Mapping

With Exchange Server 2010 Service Pack 1, the new Auto Mapping feature automatically adds mailboxes to the Outlook Navigation Pane if you have Full Access Permission to them. Outlook manages these additional mailboxes with a specific permissions set. If you previously configured these same mailboxes as multiple Exchange accounts in one Outlook profile, you may experience unexpected behavior when sending mail using those other mailboxes. This is because mailboxes accessed using the Outlook 2010 multiple Exchange accounts functionality use a different permissions set from those added by Exchange Auto Mapping. Outlook attempts to use both permission sets at the same time. To prevent this, remove the auto-mapped mailboxes from your profile using the Account Settings dialog. Because these mailboxes are automatically added via Auto Mapping, there is no need to also add them as additional Exchange accounts.

まとめ

Outlook 2010 からサポートされるようになった追加の Exchange アカウントは、Microsoft Business Productivity Online Services (BPOS) や Office 365 といったクラウドと、社内システムを同時に使用するために追加されたものと考えられます。
そのため、同じ Exchange 組織内のメールボックスを追加する場合は、追加のアカウントではなく追加のメールボックスの機能を使うべきでしょう。

Outlook 2010 で UTF8 のメッセージを受信すると文字化けする問題について

Outlook 2010 で UTF8 でエンコードされたメッセージを受信すると文字化けする場合があります。その原因としては、配信先の個人用フォルダ ファイル (以下、PST) が Unicode 非対応のものである可能性が考えられます。
Outlook 2010 で使用可能な PST には以下の 2 種類があります。

  • ANSI PST: Outlook 2002 以前の古いバージョンとの互換性のために残っている旧形式の PST
  • Unicode PST: Outlook 2003 以降で使用可能となった新しい形式の PST

そして、Outlook 2010 で ANSI PST を配信先としている場合、UTF8 のメッセージが文字化けしてしまいます。

配信先の PST が ANSI PST かどうかは、以下のようにして確認できます。

  1. [メール フォルダ] の一番上に表示されている [個人用フォルダ] を右クリックします。
  2. [データ ファイルのプロパティ] をクリックします。
  3. [詳細] をクリックします。

もし、個人用フォルダの形式が “個人用フォルダ ファイル (97-2002)” になっていれば ANSI PST です。

この場合、以下の手順で配信先の PST を新しい形式にすることで、新たに受信したメッセージで文字化けが発生しなくなります。

  1. [ファイル]-[アカウント設定]-[アカウント設定] をクリックします。
  2. 電子メール アカウントを選択し、[フォルダーの変更] をクリックします。
  3. [新しい Outlook データ ファイル] をクリックします。
  4. [ファイル名] に適切な名前を入力し、[データ ファイルの種類] で [Office Outlook 個人用フォルダ ファイル (.pst)] を選択して [OK] をクリックします。
  5. 追加したデータ ファイルの受信トレイが選択されていることを確認し、[OK] をクリックします。
  6. [閉じる] をクリックします。

なお、すでに ANSI PST で受信したメッセージを Unicode PST にコピーしただけでは、文字化けは解消されません。Unicode PST にコピーした後、以下の手順で解消することができます。

  1. 文字化けしたメッセージを開きます。
  2. [その他のアクション]-[エンコード]-[西ヨーロッパ言語 (Windows)] をクリックします。
  3. [その他のアクション]-[エンコード]-[Unicode (UTF-8)] をクリックします。
  4. メッセージを上書き保存します。

参考情報

Outlook メール文字化けの原因と対策 インターネットメール (POP3/IMAP4) 編
Outlook メール文字化けの原因と対策 Exchange Server 環境編

Outlook 2010 で送信日時や受信日時を含むメッセージの一覧をエクスポートする

以前、「送信日時や受信日時を含むメッセージの一覧をエクスポートする」という記事で任意のフィールドを CSV や Excel にエクスポートする方法を紹介しましたが、Outlook 2010 ではリボンインターフェイスの導入によりこちらの記事の手順が実行できません。
そこで、今回は Outlook 2010 においてメッセージの一覧をエクスポートする方法を紹介します。

まず、下準備としてエクスポート用のビューを以下のようにして作成します。

  1. [表示]-[ビューの変更]-[ビューの管理] をクリックします。
  2. [新規作成] をクリックします。
  3. [新しいビュー名] に "エクスポート" と入力し、[OK] をクリックします。
  4. [列] をクリックします。
  5. [表示する列と順序] でエクスポートしない列を CTRL キーを押しながら選択します。
  6. [<- 削除] をクリックします。
  7. [表示可能な列] でエクスポートしたい列を CTRL キーを押しながら選択します。
  8. [追加 ->] をクリックします。
  9. [OK] をクリックします。
  10. [その他の設定] をクリックします。
  11. [閲覧ウィンドウ] の下のラジオボタンで [オフ] を選択します。
  12. [OK] をクリックします。
  13. [OK] をクリックします。
  14. [閉じる] をクリックします。

そして、エクスポートする際には以下の手順により一覧をコピーします。

  1. [表示]-[ビューの変更] で [エクスポート] をクリックします。
  2. CTRL+A を押します。
  3. CTRL+C を押します。
  4. メモ帳を開きます。
  5. メモ帳で [編集]-[貼り付け] をクリックします。
  6. ファイル名の拡張子を .csv として保存します。
  7. [表示]-[ビューの変更] で 1. の際に選択されていたビューに戻します。

これにより、メッセージの一覧がタブ区切りの CSV ファイルとして保存されます。
なお、Excel がある場合、Excel のワークシートに直接メッセージ一覧を貼り付けることもできます。

Exchange Server 2003 環境の Outlook 2010/2007 で HTML メールを送信すると、メッセージの一部が文字化けしたり、取り消し線が引かれたりする現象について

Outlook 2010 や Outlook 2007 で HTML メールを送信すると、以下のような現象が発生することがあります。

パターン 1: メッセージ中の全角文字が半角英数字になる

この電子メール メッセージはPOP3 $B%"%+%&%s%H$N@_Dj%F%9%HCf$K!

パターン 2: メッセージ中に意味不明な全角文字が混ざる

この電子メール メッセージはw)・鹿齔瘤昭齔瘤€・

パターン 3: 意図しないところで取り消し線が引かれる

この電子メール メッセージはPOP3 アカウントの設定テスト中

このような現象は、以前このブログでも記事にしたことがありますが、すべて下記の Web ページに記載されている Exchange Server 2003 の不具合により発生します。

835992 電子メール メッセージはフォーマットできません正しく、受信者の電子メール メッセージ、Exchange Server 2003 コンピューターから別の Exchange 受信者に送信

回避策としては、Exchange Server 2003 に Service Pack 2 を適用し、以下のレジストリ設定を各サーバーで行うというものになります。

  レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent
  値の名前: TransferEncodingFor7bit
  値の種類: REG_DWORD
  値のデータ: d (10 進数で 13)

この問題の原因は、Exchange Server 2003 が iso-2022-jp などの 7 ビットの文字コードによりメッセージを送信する際に、HTML の本文を適切に折り返さないことにあります。
インターネットのメール送信に使用される SMTP の規約には 1 行が 998 文字以内という制限があるのですが、Exchange Server 2003 はこれを超える長さの HTML 本文をそのまま送信します。その結果、受信側のサーバーや経路中のサーバー、ファイアウォール、ウイルススキャンゲートウェイなどにより 1 行の長さが 998 文字を超えないようにするため強制的に改行が行われると、エスケープ シーケンスや HTML タグの途中に改行コードが埋め込まれることで、文字化けや意図しない取り消し線などが発生します。
改行コードの埋め込みがされるかどうかは中継サーバーや受信サーバーの設定によって決まるため、同じメールでも受信者によって現象が発生する場合としない場合があります。

ただ、この問題は以前から存在するにもかかわらず、最近になってこのような現象に遭遇するという事例が増えてきています。その理由は Outlook 2010/2007 が HTML メールの作成に使用している Word のコンポーネントの修正にあると考えられます。

下記の技術情報に記載されている Outlook 2007 の修正に HTML メールのソースの量を減らすというものがあります。その修正により、HTML ソースの BODY タグの中のテキストには基本的に改行が含まれなくなっています。

2203971 は、Office Word 2007 修正プログラム パッケージ (Mso ・ x ・ none.msp、Word の X-none.msp) の説明: 2010 年 6 月 29日

そして、この修正は 2010/6/29 以降にリリースされるすべての Word の修正に含まれるため、たとえば MS10-056 のようなセキュリティ修正プログラムを適用しても動作が変わります。
また、Outlook 2010 が使用する Word 2010 のコンポーネントでは、リリース当初からこのような動作となっています。

このような Word の動作により、HTML ソースの 1 行の長さが 998 文字を超える状況が発生しやすくなり、Exchange Server 2003 の不具合が顕在化してしまったのです。
残念ながら、Word の設定ではこの動作を変更することができないため、上記の Exchange Server 2003 の設定変更により対処する必要があります。

なお、HTML メールのソースの 1 行の長さには特に制限が設けられていないため、ソースに極力改行を入れないという Word の動作自体は不具合ではありません。そのため、この動作が変更されることは今後もないでしょう。
また、Outlook 2003 以前のバージョンで Word をメール エディタとして使用して HTML 形式のメールを作成した場合には、1 行の長さが 998 文字を超えることはほとんどありませんが、全く発生しないということではありません。
本文の内容によっては Outlook のバージョンや Word をエディタとして使うかどうか、またメールの形式に関わらず発生することが考えられます。そのため、Exchage Server 2003 での上記の設定を行うことが唯一の完全な回避策です。

Outlook 2010 では直接予約が既定で無効になる

Outlook で会議室などのリソースの予約を行う場合、以下の 2 通りの方法があります。

  1. Outlook でリソースのメールボックスにログオンしてリソースの設定を行い、リソースの会議室に書き込み権限を与える。
  2. Exchange サーバー側でリソースのメールボックスを監視し、会議出席依頼を送信してリソースの確保を行う。

このうち、1. を直接予約と呼び、もともとはサーバー側でリソースの管理ができない場合に、Outlook によってリソースの予約をできるようにするための機能であり、Exchange Server 2007 と Outlook 2007 の組み合わせでは直接予約はサポート対象外の使い方になります。以下は Outlook 2007 のヘルプからの抜粋です。

リソースの設定   Exchange 2007 の電子メール アカウントを新しい Exchange 予定表アシスタントと組み合わせて使用する場合、リソースの代わりに会議出席依頼に自動応答するために Outlook が使用するリソースの設定機能が動作しません。リソースの設定機能と、直接予約機能とを混同しないでください。Outlook のリソース用の自動応答機能が Exchange 2007 で動作しない理由は、Exchange 2007 予定表アシスタントが自動的にすべての会議出席依頼を処理するので、Outlook の自動応答機能が不要になるからです。Office Outlook 2007 と Exchange 2007 を一緒に使用する場合、リソースの設定機能 ([ツール] メニューの [オプション] の [予定表オプション] の [リソースの設定] コマンド) を使用して会議室を管理することはできません。Exchange 2007 のリソース予約アシスタントと呼ばれる新しい機能を使用する必要があります。この機能は、以前のリソース スケジュール機能をすべて提供します。

そして、Outlook 2010 では直接予約機能が既定で無効となり、使用する必要がある場合にはレジストリやグループポリシーなどで設定を行う必要があります。

設定方法などについては、http://support.microsoft.com/kb/982774 にスクリーンショット付の説明があるので、こちらを参照してください。ただし、このような設定をして使い続けるよりも、サーバー側でのリソース設定を使用するように運用を変更したほうがより安定して使用できるでしょう。

Outlook 2010 での開発における変更点

あけましておめでとうございます。今年もよろしくお願いします。
2010 年になったということで、新年最初の記事は Outlook 2010 に関する話です。

Office Client Developer Content and Resources ブログOutlook 2010 での開発においての変更点が公開されました。それによると以下のような変更があるようです。

Collaboration Data Objects (CDO): CDO 1.21 は Outlook 2010 ではサポートされなくなります。Outlook 2010 をインストールすると既存の CDO 1.21 のモジュールまで削除されてしまうので、CDO 1.21 を使っているようなアプリケーションは Outlook 2010 をインストールすると動作しなくなります。既存の CDO 1.21 アプリケーションは Outlook Object Model (OOM) を使用するか、MAPI を使用するように変更する必要があります。

Exchange クライアント拡張機能 (ECEs): Exchange クライアント拡張機能は Outlook 2010 では読み込まれません。ECE を使っているアドインは COM アドインで実装しなおす必要があります。主にウィルススキャンソフトのアドインなどが影響を受けそうです。

メール ウィンドウやエクスプローラ ウィンドウのコマンド バーのカスタマイズ: Outlook 2010 は全面的にリボンインターフェイスを採用するため、コマンド バーのカスタマイズは重視されない機能として位置づけられます。Outlook 2010 で直ちに使えなくなるということではありませんが、次のバージョンで使えなくなる可能性があるということです。また、アドインなどで追加されたボタンなどは [アドイン] リボンにまとめられてしまうため、使い勝手が悪くなる可能性もあります。ボタンを任意の位置に追加したいのであれば、アドインに IRibbonExtensibility を実装する必要があります。ただし、IRibbonExtensibility はフォームのスクリプトで制御できません。IRibbonExtensibility を使ったカスタマイズ方法の詳細は Extending the Interface in Outlook 2010 をご覧ください。

Application オブジェクトのイベントを使用したショートカットメニューのカスタマイズ: Application オブジェクトの ItemContextMenuDisplay などを使ってショートカット メニューをカスタマイズしている場合、Outlook 2010 では正しく動作しません。これらのイベントは CommandBars オブジェクトをイベント内で使用しますが、前述のとおり CommandBar は重視されない機能となっています。そのため、Outlook 2010 では IRibbonExtensibility を使ってショートカット メニューをカスタマイズする必要があります。

Office 2010 の 64 ビット版のサポート: Office 2010 からは、これまでの 32 ビット版だけでなく 64 ビット版の Office がリリースされます。32 ビット版でも 64 ビット版の Windows で動作しますが、64 ビット版の Office を使うことにより、メモリをより多く使用できるようになります。しかし、64 ビット版の Office プログラムでは 32 ビット版の ActiveX コントロールや DLL が読み込めません。そのため、既存の 32 ビット版のアドインなどは 64 ビット版でリビルドする必要があります。(.NET で作成された VSTO アドインなどで、CPU が Any になっている場合はリビルドの必要はありません)
なお、VBA マクロは基本的に 32 ビットで使用していたものがそのまま使えると考えられますが、マクロ内で ActiveX コントロールを呼び出している場合や、Declare により DLL の関数を使用している場合には、32 ビット版の ActiveX コントロールや DLL を使用する必要があります。
詳細については、Developing Outlook 2010 Solutions for 32-bit and 64-bit Systems もご覧ください。

MAPI を使用したアプリケーション: これまで MAPI は 32 ビットの DLL のみが利用可能であったため、MAPI アプリケーションも 32 ビットとなっていました。しかし、Office 2010 の 64 ビット版をインストールした環境で、独自に開発した MAPI アプリケーションを使用するのであれば、その MAPI アプリケーションを 64 ビットのアプリケーションとしてリビルドする必要があります。
なお、Windows が 64 ビット版であっても、Office 2010 の 32 ビット版をインストールした場合は、リビルドの必要はありません。
64 ビット版の MAPI アプリケーションの開発については Building MAPI Applications on 32-bit and 64-bit Platforms もご覧ください。

パブリック フォルダ: パブリック フォルダは Exchange Server 2007 や Exchange Server 2010 ではオプションとなっています。また、Outlook 2007 や Outlook 2010 もパブリック フォルダなしで動作します。そのため、Exchange Server 2007 以降と Outlook 2007 以降の組み合わせであれば、パブリック フォルダが存在しない構成が実現できるのですが、その場合にはパブリック フォルダを使うようなアプリケーションは使用できません。また、組織フォーム ライブラリが使用できないため、カスタム フォームは個人用フォーム ライブラリに発行するか、フォーム領域を使ってカスタマイズし、アドインとして配布する必要があります。

Outlook 97-2003 の一回限りのフォーム: 以前バージョンの Outlook では、カスタム フォームをパブリック フォルダや組織フォーム ライブラリに発行することなく、一回限りのフォーム (One-off form) としてインターネット経由で送信することができました。これを行うには、フォームのプロパティ タブの [フォームのレイアウトを送信] をオンにします。この設定により、フォームの定義が Transport Neutral Encapsulation Format (TNEF) のファイルとして添付され、受信側の Exchange サーバーや Outlook で TNEF が展開されることにより、カスタム フォームが使えるようになっていました。
しかし、Outlook 2007 以降では TNEF で添付されたカスタム フォームはサポートされなくなり、Outlook が受信したインターネット メッセージを MIME 形式から MAPI 形式に変換する際にカスタム フォームの情報を削除します。
したがって、一回限りのフォームを使用している場合は、フォーム領域によりカスタマイズし、アドインとして配布することを検討する必要があります。