今回のおもな内容 IMAPの特徴 IMAPでできない＆しないこと IMAPサーバーはどうやって手に入れるのか 事例紹介 ユーザーサポート／稟議書承認

　今回から数回に分けて、電子メールプロトコルの「IMAP （Internet Message Access Protocol）」について解説したいと思います。

　最初に、簡単に私たちとIMAPとのかかわりについてお話ししたいと思います。私たちオレンジソフトは、Windowsで動作する「Winbiff」という電子メールクライアント（メーラ）を開発、販売しています。1994年の開発当初、世間ではNetWareをはじめとするファイルサーバが普及しつつあるときでした。ファイルサーバは、どのPCでも同じファイルを参照することができるということで、瞬く間にオフィスに普及したわけですが、メーラ開発者として、メールでも同じような環境―どこでも同じようにメールを参照する―を実現したいと考えるのは、とても自然なことでした。これが私たちとIMAPの最初の出合いです。

　残念ながら当時のIMAPは、IMAP2bisというバージョンで、日本語のメールボックス名が作成できなかったり、日本語の文字列検索ができないなど、いろいろと問題があり、私たち自身のメール環境の移行は断念しました。結果、「自分たちで使えない機能を作ってもしょうがないよね」と、Winbiffへの搭載も行いませんでしたが、「いつかはIMAP」というのは私たちスタッフ間では既定の路線となっていました。

　1996年に、現在の最新バージョンであるIMAP4rev1が登場しました。このバージョンにより、上記の多くの問題は解決し、ついに私たち自身のメール環境をIMAPに移行することになりました。そして、IMAP4rev1をサポートするWinbiff V2betaをリリースしたのが1996年12月31日でした。国内外を見ても、Windowsで動作するIMAPのクライアント実装としては早い部類だったと思います。その後は、WinbiffなどのIMAP関連製品の開発・販売と、IMAP布教活動（笑）を行い、現在に至っています。

　前置きはこのくらいにしましょう。IMAPプロトコルについては、「インターネット・プロトコル詳説（8）〜（9）」で解説されていますが、少しおさらいをします。

IMAPの特徴

　IMAPは、「Internet Message Access Protocol」の略で、RFC2060（改定作業中）に規定されているプロトコルです。IMAPは、サーバに格納されたメッセージにクライアントからアクセスするための手順を規定しています。主な特徴として以下のようなもの挙げられます。

• メッセージストアをサーバに持つ
  　IMAPは、ユーザーのメッセージをサーバに保存することを基本方針として考案されたプロトコルです。ファイルサーバがファイルを格納するように、IMAPサーバはメッセージを格納します。ユーザーはIMAPのコマンドを通して（実際にはメーラがコマンドを処理するわけですが）、サーバに格納されたメッセージを読み出したり、削除などの処理を行うことができます。
• メールボックスの共有
  　メールボックスをユーザー間で共有することができ、簡単なグループウェア的な機能を提供することができます（本稿の後半で、当社で共有機能を用いた簡単な業務フローの例を紹介します）。
• モバイル環境への配慮
  　メッセージの一部を取得する機能や、同期処理のための情報提供などモバイル環境で使いやすい環境を提供します。
• 統合メッセージストア
  　IMAPはいわゆる電子メールだけでなく、NetNewsなどのRFC2822形式のメッセージにもアクセスできるように考えられています。この特徴により、IMAPは通常の電子メールだけでなく、FAXや音声などを格納する統合メッセージングサービスの基盤としても用いられています。
• 拡張機能
  　IMAPは、メッセージアクセスのための豊富な機能を提供していますが、それでも足りない機能があります。これらをフォローするために多くの拡張機能が提供されています。拡張機能については、次回以降で、そのいくつかを紹介したいと思います。

IMAPでできない＆しないこと

　IMAPは、メッセージアクセスのための豊富な機能を持っていますが、できない＆しないこともあります。具体的にいくつかの例を挙げてみます。

• メールの送信
  IMAPはメールの送信はできません。メールの送信はSMTPを用います。
• サーバの実装
  IMAPは、サーバとクライアントの間の通信手順を規定したもので、メールボックスのファイルフォーマットなどのサーバの実装方法を規定したものではありません。従って、Lotus DominoやMicrosoft Exchangeなどの独自のメールシステムでも、各社独自のメッセージアクセスプロトコルだけでなく、IMAPをサポートしていることが多々あります。
• 環境設定（ユーザープロファイル）の格納
  ユーザーの情報（名前、署名、メールアドレス、アドレス帳など）を格納することはできません。これらは、LDAPやACAPなどの別のプロトコルで行うことになります。
  ※一部のメールクライアントでは、独自の拡張でIMAPで実現している例もあります。

IMAPサーバはどうやって手に入れるのか

　Courier-IMAP、Cyrus IMAP、UW IMAP Serverなど、すでに多くの商用＆フリーのIMAP対応メールサーバが登場しています。規模や予算に応じて、これらの中からメールサーバを選択することが可能になっています。次々回にはフリーのメールサーバの導入例をご紹介する予定です。

事例紹介

　IMAPは、このように優れたメッセージプロトコルですが、多くの皆さんにとってあまり身近なものではないと思います。また、導入しようとしても、導入コストに見合ったメリットを説明できないこともあると思います。以下に、当社でのIMAPを用いた簡単な業務改善例を紹介したいと思います。

　ユーザーサポートのためのシステムは、専用システムがいくつかのベンダから提供されています（結構高価）が、当社では、IMAPの共有機能を利用し、効率化を実現しています。

　サポートでは以下の3つの共有メールボックスが利用されます（図1）。

• InComing
  サポートメールが格納されます
• Answered
  解決したメールを格納します
• tech
  サポート担当者では解決できないエンジニアのサポートが必要なメールが保存されます

図1　IMAPを利用したユーザーサポートの流れ

1. エンドユーザーからのメールは、最初にInComingに到着します。サポートスタッフは、これらのメールに対してサポート（＝メールのやりとり）を行います。個人あてに来たサポートメールもすべてInComingに移動します。
2. 1でのサポートで、問題が解決した場合、それらのメールのやりとりはスレッドごとAnsweredに移動します。もし、サポートスタッフで解決できない問題の場合は、スレッドごとtechに移動します。
3. 技術スタッフは、techに移動されたメールに対して、サポートを行います。問題が解決すると、2と同様にスレッドごとAnsweredにメールを移動します。

　この方法により、

• 効率化
  　従来は、サポートメールを個人のメールアドレスに転送することが多かったと思いますが、この場合、サポートメールと一般のメールが混在してしまい、サポートメールを見逃してしまうなどの事故がありました。共有メールボックスにより、サポートメールと一般メールは明確に区別され、見落としなどの事故はなくすことができます。
• 管理が容易
  　InComing／Answered／techは、サポート担当者個人だけでなくマネージャなども参照することができます。そのため、問い合わせの件数、停滞しているメールの数などのサポートの状況を迅速に確認することができ、サポートスタッフの増員などの手当てを迅速に行うことができます。
• 情報の共有
  　Answeredメールボックスを共有することで、過去のユーザーサポートの事例をサポートスタッフ全員が参照することができます。

　稟議書などの承認フローが必要なものを、電子メールで処理するのは意外と面倒です。担当者が申請メールを承認者に送り、承認者が承認したら、それを次の承認者に転送する……という通常の紙ベースの流れを電子メールで模倣するわけですが、一番の問題は、申請メールをだれが持っているかを確認できないということです。承認者が出張や病欠などで承認できない状態のときの処理体制が整わないと、安心して使うことができません。

　この問題は、IMAPの共有メールボックス機能と拡張機能であるアクセスコントロール機能を使うことで解決できます。

　では、当社での稟議承認の構成を紹介しましょう。承認者は1名しかおりませんので、簡単な構成ですが、拡張は容易だと思います（メールアドレス、メールボックス名は変えてあります）。また、S/MIMEの電子署名を用いるようにし、本人確認を行っています。

　ここで関与するスタッフは、以下の3者です。

• 申請者：申請書を作成、申請した担当者
• 承認者：申請書を承認する
• 処理担当者：承認された申請書に基づいて、購買などの処理を行う

　メールボックスとしては、以下に挙げるものを用います。

• 申請
  　このメールボックスには、sinsei@…あてのメールが格納されます。
  　このメールボックスは、申請者には読み取り権限を、承認者には読み取り権限と削除権限、処理担当者には読み取り権限を持たせます。
• 承認
  このメールボックスには、syonin@…あてのメールが格納されます。
  このメールボックスは、申請者には読み取り権限を、承認者には読み取り権限、処理担当者には読み取り権限を持たせます。

　申請書の流れは以下のようになります。

1. 申請者は、承認者に電子署名をした申請書メールをsinsei@…あてに送ります。
2. 承認者は、申請メールボックスのメールを確認し、承認する場合は、承認したあかしとして、S/MIMEで電子署名をして、syonin@…と申請者にメールを転送します。そして、申請メールボックスにある元メールを削除します。不承認の場合は、申請者にメールを転送し、不承認の旨を伝えます。
3. 処理担当者は、承認メールボックスを参照し、承認された申請を処理します。
4. 申請者は、メールボックスを参照することで、申請書の状態を確認することができます。

　このように、IMAPを用いることで簡単な業務フローを構築することができます。試してみてはいかがでしょうか。

　次回は、IMAPの拡張プロトコルの紹介と、実際にIMAPクライアントが送出するIMAPコマンドを解析してみたいと思います。

「連載 モバイル環境に優しいメールプロトコルIMAP」