JP2009118174A - 情報処理装置、承認方法、およびプログラム - Google Patents

Abstract

【課題】承認者が容易に電子メールの承認を行うことができるようにする。
【解決手段】電子メールの承認を行う情報処理装置が、第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを電子メールの承認者に送信する承認依頼メール送信部と、承認依頼メールに対して承認者から返信された電子メールである返信メールを取得する返信メール取得部と、返信メールの宛先に第１および第２のメールアドレスの両方が含まれている場合、および返信メールの宛先に第１のメールアドレスのみが含まれている場合のいずれか一方の場合に承認と判定し、他方の場合に非承認と判定する承認判定部と、を備える。
【選択図】図２０

Description

本発明は、情報処理装置、承認方法、およびプログラムに関する。

情報伝達の手段として電子メールが普及している。電子メールにどのような内容を記載するかは送信者の責任であり、送信者の勘違いや操作ミスによって、例えば社外秘情報などの情報が受信者に送信されると情報漏洩につながる。そこで、電子メールの送信前に承認者による承認が行われている（特許文献１および２参照）。
特開２００７−６５７８７号公報 特開２００５−３４６６４３号公報

しかしながら、特許文献１に開示される技術では、承認者に承認を行うように電子メールが送信されるが、承認者は、その電子メールに記載されたＵＲＬにＷｅｂブラウザを操作してアクセスし、Ｗｅｂブラウザを操作して承認を行う必要があるので手間がかかる。また、特許文献２に開示される技術では、承認者は、承認要請メールデータを受信し、それを所定の承認用または否認用のメールアドレスに転送することによって承認を行うことができるが、転送先として所定の承認用または否認用のメールアドレスを選択する手間がかかる。

本発明は、このような背景を鑑みてなされたものであり、承認者が容易に電子メールの承認を行うことができる情報処理装置、承認方法、およびプログラムを提供することを目的とする。

上記課題を解決するための本発明の主たる発明は、電子メールの承認を行う情報処理装置であって、第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを電子メールの承認者に送信する承認依頼メール送信部と、前記承認依頼メールに対して前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、前記返信メールの宛先に前記第１および第２のメールアドレスの両方が含まれている場合、および前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合のいずれか一方の場合に承認と判定し、他方の場合に非承認と判定する承認判定部と、を備えることとする。

その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。

本発明によれば、承認者が容易に電子メールの承認を行うことができる。

＝＝システム構成＝＝
以下、本発明の一実施形態に係る電子メールを送信するメールシステムについて説明する。本実施形態のメールシステムでは、電子メールの送信時に、電子メールの送信者とは異なる承認者からの承認を受けることを想定している。

図１は、本実施形態の係るメールシステムの全体構成を示す図である。同図に示すように、本実施形態のメールシステムは、メールサーバ１０、ユーザ端末２０、および承認者端末３０を含んで構成されている。ユーザ端末２０、承認者端末３０、およびメールサーバ１０はそれぞれ通信ネットワーク１４０に接続されており、通信ネットワーク１４０を介して互いに通信が可能である。通信ネットワーク１４０は、例えば、インターネットやＬＡＮ（Local Area Network）などであり、イーサネット（登録商標）や公衆電話回線網、無線通信網などにより構築される。本実施形態では、通信ネットワーク１４０上では、ＴＣＰ／ＩＰによる通信が行われるものとする。

ユーザ端末２０は、電子メールの送受信を行うユーザ（電子メールの送信者または受信者である。以下、ユーザ端末２０を操作するユーザをドメインユーザという。）が操作する、例えばパーソナルコンピュータやワークステーション、ＰＤＡ（Personal Digital Assistance）、携帯電話端末などのコンピュータである。ユーザ端末２０では、電子メールの送受信を行うアプリケーションソフト動作しており、いわゆるＭＵＡ（Mail User Agent）として機能している。ドメインユーザはＭＵＡを操作して電子メールの作成や送受信を行う。

承認者端末３０は、ユーザ端末２０から送信された電子メール（以下、配送メールという。）の配送を承認するユーザ（以下、承認者という。）が操作する、例えば、パーソナルコンピュータやワークステーション、ＰＤＡ、携帯電話端末などのコンピュータである。承認者端末３０もＭＵＡの機能を提供している。後述するように、承認者はＭＵＡを操作して電子メールを送信することにより承認処理を行う。本実施形態では、承認者のメールアドレス（以下、承認者アドレスという。）を送信元として、一般的な電子メールの送信は行われないものとし、承認者から送信される電子メールは、承認処理のためにのみ用いられるものとする。なお、承認者による電子メール送信の承認処理の詳細については後述する。

メールサーバ１０は、ユーザ端末２０や承認者端末３０から送信される電子メールの配送を行う、いわゆるＭＴＡ（Mail Transfer Agent）の機能を提供する、例えばパーソナルコンピュータやワークステーションなどのコンピュータである。メールサーバ１０は、ＳＭＴＰ（Simple Mail Transfer Protocol）に規定されたデータとして、ユーザ端末２０や承認者端末３０から電子メールを受け付け、受け付けた電子メールの宛先がドメインユーザのメールアドレス（以下、ドメインユーザアドレスという。）または承認者アドレスであれば、電子メールを所定の記憶領域（以下、メールボックスという。）に記憶し、それ以外であれば、電子メールを他のコンピュータに転送することにより電子メールの配送を行う。なお、メールアドレスが、ドメインユーザアドレスまたは承認者アドレスであるかどうかは、例えば、所定のドメインに所属しているか否かにより判定することができる。本実施形態では、「domain1」または「domain2」がドメインとして設定されているメールアドレスは、ドメインユーザアドレスまたは承認者アドレスであるものとする。

また、メールサーバ１０は、ユーザ端末２０や承認者端末３０からＰＯＰ（Post Office Protocol）に規定されたメール取得要求などのコマンドを受け付けて、メール取得要求に応じて、メールボックスに記憶されている電子メールの読み書きを行う。

なお、本実施形態では、メールサーバ１０が全てのユーザおよび承認者からの電子メールの配送を行う。ユーザ端末２０および承認者端末３０が電子メールの送信を行う場合には、電子メールをメールサーバ１０に送信し、電子メールの受信を行う場合には、電子メールを取得するコマンド（以下、メール取得要求という。）をメールサーバ１０に送信するものとする。

本実施形態では、メールサーバ１０は、配送すべき電子メール（以下、配送メールという。）の配送時に承認者による承認を受けることを想定している。
メールサーバ１０は、配送メールを配送してもよいかどうかを問い合わせる電子メール（以下、承認依頼メールという。）を承認者宛てに作成してメールボックスに格納する。承認依頼メールのヘッダには、承認者アドレスが宛先（Ｔｏ）フィールドに設定され、所定のメールアドレスである第１の管理者アドレス（admin01@domain1）が送信元（Ｆｒｏｍ）のフィールドに設定され、さらに、所定のメールアドレスである第２の管理者アドレス（admin02@domain1）が宛先（ＴｏまたはＣｃ）として設定される。

これに対する承認者からの返信の電子メールには、宛先として承認依頼メールの送信元である第１の管理者アドレスが設定される。ここで、宛先に第２の管理者アドレスも加えられている場合、メールサーバ１０は、配送メールの配送が承認されたと判断する。逆に第１の管理者アドレスのみが宛先となっている場合には、メールサーバ１０は、配送メールの配送が承認されなかったと判断する。

一般的なＭＵＡは、受信した電子メールの送信元（ＦｒｏｍフィールドまたはＲｅｐｌｙ−Ｔｏフィールドに設定されている返信先）に対して返信する電子メール（以下、返信メールという。）を送信する「返信」機能と、送信元、宛先およびカーボンコピーの全てに対して応答メールを送信する「全員に返信」機能とを備えている。

したがって、承認者は、承認依頼メールに対して、ＭＵＡの「全員に返信」機能により返信した場合には、配送メールの配送を承認したことになり、ＭＵＡの「返信」機能により返信した場合には、配送メールの配送を承認しなかったことになる。このように、本実施形態のメールシステムでは、一般的なＭＵＡの機能を利用して、承認者が容易に承認処理を行うことができるようにしている。

以下、詳細について説明する。

＝＝ハードウェア＝＝
図２は、本実施形態のメールシステムのハードウェア構成を示す図である。
同図に示すように、メールサーバ１０は、ＣＰＵ１０８、主記憶装置１０１、通信インタフェース１０９、ディスクインタフェース１１０、およびディスクインタフェース１１０に接続されたハードディスク装置１１４を備えている。

ハードディスク装置１１４は、各種のプログラムやデータを記憶する記憶装置である。ハードディスク装置１１４に代えて、フラッシュメモリやＣＤ−ＲＯＭドライブなどの記憶装置を採用するようにしてもよい。主記憶装置１０１には、サーバプログラム１０２が記憶されている。サーバプログラム１０２は、ハードディスク装置１１４から主記憶装置１０１に読み出すようにしてもよいし、通信ネットワーク１４０を介して他のコンピュータから受信するようにしてもよい。ＣＰＵ１０８は、主記憶装置１０１に記憶されているサーバプログラム１０２などのプログラムを実行することにより各種の機能を実現する。

通信インタフェース１０９は、通信ネットワーク１４０に接続するためのインタフェースであり、例えば、イーサネット（登録商標）に接続するためのアダプタや、公衆電話回線網に接続するためのモデム、無線通信網に接続するための無線通信装置などである。

ディスクインタフェース１１０は、ハードディスク装置１１４と接続するためのインタフェースであり、例えば、ＳＣＳＩ（Small Computer System Interface）やＩＤＥ（Integrated Drive Electronics）、ＳＡＮ（Storage Area Network）などのプロトコルに従ってハードディスク装置１１４にアクセスする。ＣＰＵ１０８は、ディスクインタフェース１１０を介してハードディスク装置１１４に対するデータの入出力を行う。

なお、ハードディスク装置１１４は、メールサーバに内蔵する形態としてもよいし、メールサーバ１０とは別体の独立した記憶装置としてもよい。また、ＮＡＳ（Network Attached Storage）のように、他のコンピュータが管理する記憶装置にアクセスするようにしてもよい。

ユーザ端末２０および承認者端末３０は、同じハードウェア構成である。図２に示すように、ユーザ端末２０および承認者端末３０はそれぞれ、ＣＰＵ１２７、主記憶装置１２１、通信インタフェース１２８、ディスクインタフェース１２９、入出力インタフェース１３０、ディスクインタフェース１２９に接続されたハードディスク装置１３３および入出力インタフェース１３０に接続された入出力装置１３２を備えている。

入出力装置１３２は、データの入出力を行う、例えば、キーボードやマウス、タッチパネル、ディスプレイ、プリンタなどである。ユーザ端末２０および承認者端末３０は、通常キーボード、マウスおよびディスプレイなどの複数の入出力装置１３２を備える。

＝＝ソフトウェア＝＝
図３は、本実施形態のメールシステムの機能構成を示す図である。
ユーザ端末２０および承認者端末３０は同じ機能を有し、それぞれ制御部１２３、メール表示部１２４、メール受信部１２５、メール送信部１２６、およびメールデータ記憶部１３１を備えている。
メール表示部１２４、メール受信部１２５およびメール送信部１２６は、ユーザ端末２０および承認者端末３０が備えるＣＰＵ１２７が主記憶装置１２１に記憶されているクライアントプログラム１２２を実行することにより実現される。また、メールデータ記憶部１３１は、ユーザ端末２０および承認者端末３０が備える主記憶装置１２１やハードディスク装置１３３が提供する記憶領域として実現される。なお、制御部１２３、メール表示部１２４、メール受信部１２５、メール送信部１２６、およびメールデータ記憶部１３１は、一般的なＭＵＡの機能である。

制御部１２３は、メール表示部１２４、メール受信部１２５、メール送信部１２６の制御を行う。

ユーザが入出力装置１３２において電子メールの送信を指示するコマンドを入力した場合、制御部１２３は、ユーザが入出力装置１３２において入力した電子メールの内容（以下、メールデータという。）を、入出力インタフェース１３０を介して受け付ける。制御部１２３は、受け付けたメールデータをメール送信部１２６に渡す。メール送信部１２６は制御部１２３から受け取ったメールデータを記述した電子メールを作成し、作成した電子メールを、通信インタフェース１２８を介してメールサーバ１０に送信する。なお、メール送信部１２６は、ＳＭＴＰに規定される電子メールの送信要求として電子メールを送信する。

ユーザが入出力装置１３２において電子メールの受信を指示するコマンドを入力した場合、制御部１２３は、ユーザが入出力装置１３２において入力した、ユーザを特定するユーザＩＤやパスワードを、入出力インタフェース１３０を介して受け付ける。なお、ユーザＩＤやパスワードは、主記憶装置１２１やハードディスク装置１３３などに予め記憶しておくようにしてもよい。制御部１２３は、ユーザＩＤおよびパスワードをメール受信部１２５に渡す。メール受信部１２５は、ユーザＩＤおよびパスワードを設定したメール取得要求をメールサーバ１０に送信し、メールサーバ１０がメール取得要求に応じて送信する電子メールを受信して、受信した電子メールをメールデータとして、ディスクインタフェース１２９を介してメールデータ記憶部１３１に記憶する。

ユーザが入出力装置１３２において電子メールの表示を指示するコマンド（以下、メール表示要求という。）を入力した場合、制御部１２３は、メール表示要求をメール表示部１２４に通知する。メール表示部１２４は、メールデータ記憶部１３１からメールデータを読み出し、読み出したメールデータを、入出力インタフェース１３０を介して入出力装置１３２に渡して、入出力装置１３２が受け取ったメールデータを出力する。これにより、ユーザは電子メールの内容を閲覧することができる。なお、電子メールの受信を指示するコマンドを受け付けた場合に、電子メールの受信と表示との両方の処理を行ってもよい。

メールサーバ１０は、制御部１０３、メール受付部１０４、メール送信部１０５、承認処理部１０６、監視処理部１０７、メールボックス１１１、承認者テーブル１１２、承認待ちテーブル１１３、および送信待ちキュー１１４を備えている。

制御部１０３、メール受付部１０４、メール送信部１０５、承認処理部１０６、および監視処理部１０７（本発明のタイムアウト監視部に該当する。）は、メールサーバ１０が備えるＣＰＵ１０８が、主記憶装置１０１に記憶されるサーバプログラム１０２を実行することにより実現される。メールボックス１１１、承認者テーブル１１２、承認待ちテーブル１１３、および送信待ちキュー１１４は、メールサーバ１０が備える主記憶装置１０１やハードディスク装置１１４が提供する記憶領域として実現される。

メール送信部１０５（本発明の電子メール送信部に該当する。）は、電子メールの配送を行う。メール送信部１０５は、電子メールの宛先がドメインユーザアドレスまたは承認者アドレスである場合には、宛先のメールアドレスに対応付けてメールボックス１１１に電子メールを格納し、宛先がそれ以外のアドレスである場合には、他のＭＴＡや中継サーバなどに電子メールを転送することにより、電子メールの配送を行う。

メール受付部１０４（本発明の電子メール受信部に該当する。）は、通信ネットワーク１４０を介して、ユーザ端末２０や承認者端末３０、他のＭＴＡ、中継サーバなどから送信される電子メールを受信する。メール受付部１０４は電子メールを受信すると、電子メールを受け付けた旨を制御部１０３に通知する。

制御部１０３は、メールを受け付けた旨の通知（受付通知）を検知し、承認処理部１０６に、メール受付部１０４が受信した電子メールを渡す。

承認処理部１０６は、制御部１０３から受け取った電子メール（以下、受信メールという。）を解析し、この受信メールの配送に承認が必要であるかどうかを判定する。承認が必要であるか否かは、受信メールの送信先に設定されているメールアドレスが、ドメインユーザアドレスであるか否か、および、受信メールの送信者に対応する承認者が登録されているか否かに応じて判断される。

送信者に対応する承認者は承認者テーブル１１２に登録される。図４は、承認者テーブル１１２の構成例を示す図である。同図に示すように、承認者テーブル１１２は、送信者のメールアドレス８１１に対応付けて、承認者アドレス８１２を記憶している。

本実施形態では、承認処理部１０６は、電子メールの送信先がドメインユーザである場合か、送信者に対応する承認者が承認者テーブル１１２に登録されていない場合に、受信メールの承認は不要と判定する。

承認処理部１０６が受信メールについて承認不要と判断した場合、メール送信部１０５は、受信メールの配送を行う。

承認処理部１０６は、承認が必要であると判断した受信メール（以下、配送メールという。）を送信待ちキュー１１４に格納する。

図５は、受信メール９００の構成例を説明する図である。配送メール９００は、エンベロープ情報９０１、ヘッダ部９０２およびボディ部９０３により構成されている。図４の例では、配送メール９００のボディ部９０３には、本文９０４が含まれている。

エンベロープ情報９０１は、ＳＭＴＰでやりとりされる際に電子メールに付帯される情報であり、電子メールの送信元（エンベロープＦｒｏｍ）と送信先（エンベロープＴｏ）とが記述される。

ヘッダ部９０２およびボディ部９０３は、メールサーバ１０においてメールボックス１１１に記憶される情報であり、ユーザ端末２０および承認者端末３０においてメールデータ記憶部１３１に登録され、メール表示部１２４により出力される情報である。ヘッダ部９０２にも、送信元（Ｆｒｏｍ）と送信先（Ｔｏ）とが設定されるが、ＭＴＡにおいて送信元とエンベロープＴｏとが異なり、あるいは送信先とエンベロープＴｏとが異なるように書き換わることもある。ヘッダ部９０２には、題名（Ｓｕｂｊｅｃｔ）など各種のフィールドが含まれる。ボディ部９０３には、本文９０４や添付ファイルなど、電子メールの内容となる各種の情報が記述される。

図６は、送信待ちキュー１１４（本発明の電子メール記憶部に該当する。）の構成例を示す図である。送信待ちキュー１１４に格納される配送メールには識別情報（以下、キューＩＤという。）が割り当てられる。本実施形態では、送信待ちキュー１１４は、ファイルシステムにおけるディレクトリとして実現され、送信待ちキュー１１４には、配送メールがキューＩＤをファイル名としたファイルとして格納されるものとする。

承認処理部１０６は、送信待ちキュー１１４に格納した配送メールについて、承認者に承認依頼メールを送信し、承認待ちの状態になった配送メールに関する情報（以下、承認待ち情報という。）を承認待ちテーブル１１３に登録する。

図７は、承認待ちテーブル１１３に登録される承認待ち情報の構成例を示す図である。同図に示すように、承認待ち情報は、承認依頼メールの識別情報（メッセージＩＤ；Message-ID）８０１に対応付けて、配送メールのキューＩＤ８０２、配送メールの送信者８０３、承認者アドレス８０４、および、承認待ち情報を登録した日時（受付日時）８０５を含んでいる。承認待ちテーブル１１３に登録されているキューＩＤが示す配送メールは、承認者による承認を待っている状態であることを示す。

承認処理部１０６は、承認者からの返信メールに応じて、承認されたか否かを判定する。なお、承認処理部１０６による配送メールの承認処理の詳細については後述する。

承認処理部１０６が配送メールについて配送が承認されたと判定した場合には、メール送信部１０５は、配送メールを配送する。

承認待ちテーブル１１３に登録された承認待ち情報は、登録されてから所定時間経過後に監視処理部１０７により削除される。図８は、監視処理部１０７による承認待ち情報の監視処理の流れを示す図である。

監視処理部１０７は、登録から所定時間（例えば、３時間や６時間、２４時間など、任意に設定できるものとする。）経過した承認待ち情報、すなわち、受付日時から所定時間後の日時よりも現在日時が後になるものを、承認待ちテーブル１１３から取得し（ステップ７００）、取得した承認待ち情報のそれぞれについて以下の処理を行う（ステップ７０１）。

監視処理部１０７は、承認待ち情報の送信者８０３を宛先として、所定時間内に承認がなかった旨のメッセージを本文として設定した電子メールを作成し、メール送信部１０５が、この電子メールを配送する（ステップ７０２）。

また、監視処理部１０７は、承認待ち情報の承認者８０４を宛先として、承認依頼メールへの回答がなかった旨のメッセージを本文として設定した電子メールを作成し、メール送信部１０５が、この電子メールを配送する（ステップ７０３）。

監視処理部１０７は、承認待ち情報のキューＩＤ８０２が示すファイルを送信待ちキュー１１４から削除し（ステップ７０４）、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ７０５）。

監視処理部１０７が以上の処理を繰り返して、登録から所定時間を経過した承認待ち情報を削除する。

＝＝承認処理＝＝
図９は、承認処理部１０６の詳細構成を示す図である。承認処理部１０６は、承認結果判定処理部２００、承認判定処理部２０１、承認依頼メール作成処理部２０２、および通知メール作成処理部２０３を備えている。

承認結果判定処理部２００（本発明の返信メール取得部および承認判定部に該当する。）は、受信メールと承認待ちテーブル１１３の承認待ち情報とを比較して、受信メールが返信メールであるか否かを判定し、受信メールが返信メールであると判断した場合は、承認の結果を通知メール作成処理部２０３に渡す。通知メール作成処理部２０３（本発明の第１および第２のエラー通知部に該当する。）は、承認の結果を通知する電子メールを作成し、メール送信部１０５がその電子メールを配送する。

承認結果判定処理部２００が、受信メールが承認者からの返信メールではないと判断した場合には、承認依頼判定処理部２０１が、受信メールについて承認が必要であるか否かを判断する。承認依頼判定処理部２０１は、承認必要と判断した場合、受信メールを配送メールとして送信待ちキュー１１４に格納するとともに、承認待ちテーブル１１３へ承認待ち情報を登録する。

さらに承認依頼判定処理部２０１は、配信メールの送信者に対応する承認者アドレスを承認者テーブル１１２から取得し、取得した承認者アドレスを承認依頼メール作成処理部２０２に渡す。

承認依頼メール作成部２０２（本発明の承認依頼メール送信部に該当する。）は、受け取った承認者アドレスを宛先とした承認依頼メールを作成し、メール送信部１０５は、承認依頼メールを配送する。

承認依頼判定処理部２０１は、受信メールが承認不要と判断した場合には、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する。

以下、承認処理部１０６による承認処理について詳述する。
図１０は、承認結果判定処理部２００が、受信メールの宛先に応じて、受信メールが承認者からの返信メールであるか否かを判定する処理の流れを示す図である。

承認結果判定処理部２００は、受信メールのエンベロープ情報に含まれている宛先（エンベロープＴｏ）がなくなるまでステップ３０２の処理を繰り返す（ステップ３００）。

承認結果判定処理部２００は、エンベロープＴｏに設定されている宛先のメールアドレス（以下、受信者アドレスという。）を取得し（ステップ３０１）、取得した受信者アドレスが第１の管理者アドレス（admin01@domain1）であるか否かを判定する（ステップ３０２；承認回答判定部）。

受信者アドレスが第１の管理者アドレスであれば（ステップ３０２：ＹＥＳ）、受信メールは承認者からの返信メールと判定され、承認結果判定処理部２００は後述の図１９のステップ３２０に進み、承認者による承認結果に応じた処理を行う。

一方、すべての受信者アドレスが第１の管理者アドレスでなければ（ステップ３０２：ＮＯ）、図１１のステップ３１０に進む。
図１１は、承認結果判定処理部２００が受信メールの解析を行い、受信メールがどのような電子メールであるのかを判定する処理の流れを示す図である。
承認結果判定処理部２００は、受信メールに含まれるReferencesヘッダからMessage-IDを取得する（ステップ３１０；返信先取得部）。承認結果判定処理部２００は、ReferenceヘッダからMessage-IDを取得できた場合（ステップ３１１：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定し（ステップ３１２）、登録されていれば（ステップ３１２：ＹＥＳ）、後述のステップ３１７に進み、登録されていなければ（ステップ３１２：ＮＯ）、ステップ３１３に進む。

承認結果判定処理部２００は、ReferencesヘッダからMessage-IDを取得できなかった場合（ステップ３１１：ＮＯ）または、取得したMessage-IDが承認待ちテーブル１１３に登録されていなかった場合（ステップ３１２：ＮＯ）には、受信メールのヘッダ情報に含まれるIn-Reply-ToヘッダからMessage-IDを取得する。

承認結果判定処理部２００は、In-Reply-ToヘッダからMessage-IDを取得できた場合（ステップ３１４：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３１５）。

承認結果判定処理部２００は、In-Reply-Toヘッダにも、承認依頼メールのMessage-IDが設定されていない場合（ステップ３１５：ＮＯ）、には、図１２に示す承認依頼判定処理部２０１による処理が行われる（ステップ３１６）。

図１２は、承認依頼判定処理部２０１が受信メールの解析を行い、受信メールに承認が必要か否かの判定を行う処理の流れを示す図である。
承認依頼判定処理部２０１は、受信メールのエンベロープ情報に含まれるエンベロープＴｏがなくなるまで以下の処理を繰り返す（ステップ４００）。
承認依頼判定処理部２０１は、受信メールのエンベロープ情報に含まれるエンベロープＴｏに設定されている受信者アドレスを取得し（ステップ４０１）、取得した受信者アドレスが所属するドメインが、「domain1」および「domain2」のいずれでもないか否かにより、承認が必要か否かを判定する（ステップ４０２；承認要否決定部）。なお、受信者アドレスに応じて承認が必要か否かを判断することに限らず、本文や添付ファイルの内容などに応じて承認が必要か否かを判断するようにしてもよい。

承認依頼判定処理部２０１は、すべての受信者アドレスについて承認が不要と判断した場合には（ステップ４０２：ＹＥＳ）、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する（ステップ４０３）。

一方、承認依頼判定処理部２０１は、受信者アドレスのいずれかについて承認が必要と判断した場合には（ステップ４０２：ＮＯ）、エンベロープ情報から送信元（エンベロープＦｒｏｍ）のメールアドレス（以下、送信者アドレスとう。）を取得し（ステップ４０４）、送信者アドレスに対応する承認者アドレスを承認者テーブル１１２から検索する。

承認依頼判定処理部２０１は、送信者アドレスに対応する承認者アドレスが見つからなかった場合には（ステップ４０５：ＮＯ）、受信メールの承認は不要として、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する（ステップ４０６）。なお、ステップ４０２において承認が必要と判定された場合には、ステップ４０５における判定処理を行わずに、ステップ４０７に進むようにしてもよいし、受信メールの送信者やメールシステムの管理者宛てに、承認者テーブル１１２に承認者が設定されていない旨を示す電子メールを送信するようにしてもよい。

一方、送信者アドレスに対応する承認者アドレスが見つかった場合には（ステップ４０５：ＹＥＳ）、承認が必要と判断され、図１３に示す承認依頼メール作成処理部の処理が行われる。

図１３は、承認依頼メール作成処理部２０２による承認依頼メールの作成処理の流れを説明する図である。
承認依頼メール作成処理部２０２は、受信メールにユニークなキューＩＤを割り当て、割り当てたキューＩＤをファイル名にして受信メールを配送メールとして送信待ちキュー１１４に格納する（ステップ５００）。

承認依頼メール作成処理部２０２は、承認依頼判定処理部２０１がステップ４０５で取得した承認者アドレスをヘッダのＴｏフィールドに設定し、第１の管理アドレス（admin01@domain1）をヘッダのＦｒｏｍフィールドに設定し、第２の管理アドレス（admin02@domain1）をヘッダのＣｃフィールドに設定し、ユニークなMessage-IDを生成してヘッダに設定した承認依頼メールを新規に作成する（ステップ５０１）。

図１４は、承認依頼メール作成処理部２０２が作成する承認依頼メール９１０の構成例を示す図である。承認依頼メール９１０も、通常の電子メールと同じくエンベロープ情報９１１、ヘッダ部９１２、およびボディ部９１３から構成される。

エンベロープ情報９１１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。承認依頼メール９１０の配送時にエラーが発生した場合には、第１の管理者アドレス宛に承認依頼メール９１０が転送される。エンベロープ情報９１１に含まれるエンベロープＴｏには、承認依頼判定処理部２０１がステップ４０５で取得した、送信者アドレス（aaa@domain1）に対応する承認者アドレス（zzz@domain1）が設定される。

ヘッダ部９１２には、承認依頼メール９１０の識別情報であるMessage-IDや、送信元（Ｆｒｏｍ）フィールド、宛先（Ｔｏ）フィールド、カーボンコピー（Ｃｃ）フィールドなどが含まれる。Message-IDは、一般ユーザに容易に推測されないように、例えば、乱数などを用いて作成する。

Ｆｒｏｍフィールドには、上記エンベロープＦｒｏｍと同様に、第１の管理者アドレス（admin01@domain1）が設定される。したがって、承認者がこの承認依頼メール９１０に対して返信をした場合には、宛先に第１の管理者アドレスが含まれることになり、上述したように、図１０の処理において、Ｆｒｏｍフィールドに第１の管理者アドレスが設定されているか否かにより、メールサーバ１０が受信した電子メールが承認者からの返信メールであるか否かが判定される。

Ｔｏフィールドには、エンベロープＴｏと同じく、承認者アドレス（zzz@domain1）が設定される。

Ｃｃフィールドには、第２の管理者アドレス（admin02@domain1）が設定される。承認者がＭＵＡの「全員に返信」機能を用いて承認依頼メールに対して返信を行った場合には、Ｃｃフィールドに設定されていた第２の管理者アドレスも、返信メールのＴｏフィールドあるいはＣｃフィールドに設定される。後述するように、本実施形態のメールサーバ１０は、承認者からの返信メールの宛先（ＴｏフィールドおよびＣｃフィールド）に第１の管理者アドレスのみが設定されている場合には「非承認」、宛先に第１および第２の管理者アドレスの両方が設定されている場合には「承認」と判定する。

なお、第２の管理者アドレスは、「admin02@domain1」に限らず、例えば、承認者が「承認」の返信を行うことが容易に確認できるような名称、例えば「SYOUNIN.OK@domain」のようにしてもよい。これにより、承認者は、「承認」とする結果を返信しようとしていることをＭＵＡにおいて容易に確認することができるので、承認者の作業ミスを減らすことができる。
件名（Subject）フィールドには、承認者に対して承認依頼要求が来ていることがわかるような文字列を設定することが望ましい。

ボディ部９１３には、本文９１４および添付ファイル９１５が含まれる。
本文９１４には、承認者に承認依頼が来ていることを示すメッセージと、承認の対象となる配送メールのエンベロープ情報とが記載される。また、本文９１４には、配送を承認する場合は「全員へ返信」により返信を行い、非承認とする場合は「返信」により返信を行うように指示するインストラクションを記述する。これにより承認者の作業ミスを減らすことができる。

添付ファイル９１５は、承認の対象となる配送メールである。このように承認が必要となった配送メール自体を添付することで、承認者がその電子メールの本文の内容や添付ファイル、宛先のメールアドレスなどを確認することができる。

図１１に戻り、Referencesヘッダに含まれるMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３１２：ＹＥＳ）またはIn-Reply-Toに含まれるMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３１５：ＹＥＳ）には、第１の管理者アドレスが設定されていないにも関わらず、承認依頼メールへの返信として送信された電子メールが受信されたことになる。例えば、承認者がＭＵＡにおいて返信の操作をした際に、第１の管理者アドレスを宛先から除外してしまったような場合に、このような電子メールが受信されることになる。承認結果判定処理部２００は、不正な電子メールを受信したと判定し（ステップ３１７）、図１５に示す、通知メール作成処理部２０３によるエラー処理が行われる（ステップ３１８）。

図１５は、通知メール作成処理部２０３によるエラー処理の流れを示す図である。
通知メール作成処理部２０３は、承認待ちテーブル１１３から、承認結果判定処理部２００が上記図１１のステップ３１０またはステップ３１３で取得したMessage-IDに対応する承認待ち情報を取得する（ステップ６００）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、エラーが発生した旨を示すメッセージを含む電子メール（以下、エラーメールという。）を送信する（ステップ６０１）。

図１６は、通知メール作成処理部２０３が作成するエラーメール９４０の構成例を示す図である。エラーメール９４０には、エンベロープ情報９４１、ヘッダ部９４２、ボディ部９４３が含まれる。エンベロープ情報９４１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイルに格納されている配送メールの送信者（承認待ち情報の送信者８０３）が設定される。ヘッダ部９４２に含まれる件名（Ｓｕｂｊｅｃｔ）フィールドには、エラーが発生した旨の示す文字列が記載される。ボディ部９４３にふくまれる本文９４４には、どのようなメールアドレスを宛先とした配送メールに対しての承認が失敗したかを示すメッセージや、配送メールの件名、送信日時などを記載する。添付ファイル９４５には、配信メールである。これにより、配送メールの送信者は、エラーが発生した電子メールを容易に確認することができる。

次に通知メール作成処理部２０３は、承認待ち情報のキューＩＤ８０２が示すファイルを送信待ちキュー１１４から削除し（ステップ６０２）、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ６０３）。すなわち、承認待ち状態であった配送メールが破棄されたことになる。

以上のようにして、承認依頼メール９１０が承認者に配送されると、承認者は配送メールの配送の承認、非承認を判断する。

承認者は、配送を非承認とする場合には、ＭＵＡの「返信」機能を用いて、承認依頼メール９１０のＦｒｏｍフィールドに設定されていた第１の管理者アドレス（admin01@domain1）のみを宛先とした返信メールをメールサーバ１０に送信する。非承認を表す返信メール９２０の構成例を図１７に示す。非承認の返信メール９２０には、エンベロープ情報９２１、ヘッダ部９２２、およびボディ部９２３が含まれ、エンベロープ情報９２１に含まれるエンベロープＦｒｏｍには承認者アドレスが設定され、エンベロープＴｏには、第１の管理者アドレス（admin01@domain1）のみ設定される。また、ヘッダ部９３１に含まれるReferencesヘッダ（またはIn-Reply-Toヘッダ）には承認依頼メール９１０のMessage-IDが設定される。これによりメールサーバ１０は、返信メール９２０が承認依頼メール９１０に対する返信と判断することができる。なお、承認者は、非承認とする理由を入力し、入力した理由をボディ部９２３に含まれる本文９２４として設定するようにしてもよい。この場合、送信者が非承認の理由を知ることができる。なお、ここで承認者は、送信者を宛先やカーボンコピーに追加するようにしてもよい。これにより、非承認の理由を直接送信者に送信することができる。

一方、承認者が配送を承認する場合には、ＭＵＡの「全員に返信」機能を用いて、承認依頼メール９１０のＦｒｏｍフィールドおよびＣｃフィールドに設定されていた第１および第２の管理者アドレス（admin01@domain1およびadmin02@domain1）を宛先として設定した返信メールを返信する。承認を表す返信メール９３０の構成例を図１８に示す。返信メール９３０には、エンベロープ情報９３１、ヘッダ部９３２、およびボディ部９３３が含まれる。エンベロープ情報９３１に含まれるエンベロープＦｒｏｍには承認者アドレスが設定され、エンベロープＴｏには第１の管理者アドレス（admin01@domain1）および第２の管理者アドレス（admin02@domain1）の両方が設定される。ヘッダ部９３２に含まれるReferencesヘッダ（またはIn-Reply-Toヘッダ）には、承認依頼メール９１０のMessage-IDが設定される。これによりメールサーバ１０は、返信メール９３０が承認依頼メール９１０に対する返信であることを判断することができる。

ここで図１０に戻り、受信メールの受信者アドレスに第１の管理者アドレスが含まれていた場合には（ステップ３０２：ＹＥＳ）、受信メールは承認者からの返信メールとして、図１９のステップ３２０に進む。
図１９は、承認結果判定処理部２００が返信メールの解析を行い、返信メールがどのようなメールであるのかを判定する処理の流れを示す図である。
承認結果判定処理部２００は、返信メールに含まれるReferencesヘッダからMessage-IDを取得する（ステップ３２０）。承認結果判定処理部２００は、ReferenceヘッダからMessage-IDを取得できた場合（ステップ３２１：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３２２）。

承認結果判定処理部２００は、ReferencesヘッダからMessage-IDを取得できなかった場合（ステップ３２１：ＮＯ）または、取得したMessage-IDが承認待ちテーブル１１３に登録されていなかった場合（ステップ３２２：ＮＯ）には、返信メールに含まれるIn-Reply-ToヘッダからMessage-IDを取得する（ステップ３２３）。

承認結果判定処理部２００は、In-Reply-ToヘッダからMessage-IDを取得できた場合（ステップ３２４：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３２５）。

承認結果判定処理部２００は、In-Reply-ToヘッダからもMessage-IDを取得できなかった場合（ステップ３２４：ＮＯ）、すなわち、返信メールの宛先に第１の管理者アドレスが設定されていたにも関わらず、返信メールの返信先を取得できなかった場合、または、In-Reply-Toヘッダから取得したMessage-IDが承認待ちテーブル１１３に登録されていない場合（ステップ３２５：ＮＯ）、すなわち、返信先の承認依頼メールに対応する配信メールが存在しない場合には、不正な返信メールを取得したと判定して、当該返信メールを破棄して処理を終了する（ステップ３２６）。なお、返信先の承認依頼メールに対応する配信メールが存在しない場合とは、例えば、監視処理部１０７により、所定時間内に承認、非承認の判定がなされなかった配送メールおよび対応する承認待ち情報が削除された場合である。

承認結果判定処理部２００は、ReferencesヘッダまたはIn-Reply-Toヘッダから取得したMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３２２：ＹＥＳまたはステップ３２５：ＹＥＳ）、取得したMessage-IDに対応する承認者８０４を承認待ちテーブル１１３から取得し（ステップ３２７）、図２０のステップ３３０に進む。

図２０は、承認結果判定処理部２００が返信メールの解析を行い、承認または非承認の判定を行う処理の流れを示す図である。
承認結果判定処理部２００は、返信メールのエンベロープ情報から送信元（エンベロープＦｒｏｍ）の送信者アドレスを取得する（ステップ３３０）。承認結果判定処理部２００は、取得した送信者アドレスと、図１９のステップ３２７で取得した承認者アドレスとを比較する（ステップ３３１）。これらが一致しなければ（ステップ３３１：ＮＯ）、上述した図１５の通知メール作成処理部２０３によるエラー処理が行われる（ステップ３３２）。

承認結果判定処理部２００は、返信メールのエンベロープ情報に含まれているエンベロープＴｏがなくなるまで、ステップ３３４およびステップ３３５の処理を繰り返す（ステップ３３３）。

承認結果判定処理部２００は、返信メールのエンベロープ情報に含まれるエンベロープＴｏから受信者アドレスを取得し（ステップ３３４）、取得した受信者アドレスが第２の管理者アドレス（admin02@domain1）と一致するか否かを判定する（ステップ３３５）。

エンベロープＴｏに第２の管理者アドレスが含まれていない場合には（ステップ３３５：ＮＯ）、図２１に示す通知メール作成処理部２０３による非承認処理が行われる（ステップ３３６）。

図２１は、通知メール作成処理部２０３による非承認処理の流れを示す図である。
通知メール作成処理部２０３は、上記図１９の処理において承認結果判定処理部２００が取得したMessage-IDに対応する承認待ち情報を、承認待ちテーブル１１３から取得する（ステップ６１０）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、配信メールが非承認であった旨を示すメッセージを含む電子メール（以下、非承認メールという。）を送信し（ステップ６１２）、承認待ち情報を承認待ちテーブル１１３から削除する。

上記非承認処理により作成される非承認メール９５０の構成例を図２２に示す。
非承認メール９５０は、エンベロープ情報９５１、ヘッダ部９５２およびボディ部９５３を含んでいる。エンベロープ情報９５１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイル名に格納されている配送メールの送信元（Ｆｒｏｍフィールドに設定されているメールアドレス）を設定する。
ヘッダ部９５２に含まれる件名フィールドには、送信者が承認結果をすぐに認識できるように「非承認」である旨を記載する。
ボディ部９５３に含まれる本文９２４には、配送メールの宛先や、件名、送信日時など、送信者が配送メールを特定しやすい情報を記述する。また、承認者からの返信メールの本文に非承認とした理由が含まれている場合には、その理由を本文９２４にも記載するようにする。また、返信メールを添付ファイルとしてボディ部９５３に含めるようにしてもよい。さらに、配送メールを添付ファイルとしてボディ部９５３に含めるようにしてもよい。これによりどのような内容の配信メールが非承認とされたのかを送信者が容易に把握することができる。

一方、図２０の処理において、返信メールのエンベロープＴｏに第２の管理者アドレスが含まれていた場合には（ステップ３３５：ＹＥＳ）、図２３に示す、通知メール作成処理部２０３による承認処理が行われる（ステップ３３７）。

図２３は、通知メール作成処理部２０３による承認処理の流れを示す図である。
通知メール作成処理部２０３は、上記図１９の処理において承認結果判定処理部２００が取得したMessage-IDに対応する承認待ち情報を、承認待ちテーブル１１３から取得する（ステップ６２０）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、配信メールが承認された旨を示すメッセージを含む電子メール（以下、承認メールという。）を送信し（ステップ６２２）、承認待ち情報のキューＩＤ８０２をメール送信部１０５に通知して、メール送信部１０５は、キューＩＤが示すファイルに格納されている配送メールを配送する（ステップ６２３）。通知メール作成処理部２０３は、承認待ち情報を承認待ちテーブル１１３から削除する。
図２３の承認処理において作成される承認メール９６０の構成例を図２４に示す。

承認メール９６０は、エンベロープ情報９６１、ヘッダ部９６２およびボディ部９６３を含んでいる。エンベロープ情報９６１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイル名に格納されている配送メールの送信元（Ｆｒｏｍフィールドに設定されているメールアドレス）を設定する。
ヘッダ部９６２に含まれる件名フィールドには、送信者が承認結果をすぐに認識できるように「承認」の旨を記載する。
ボディ部９６３に含まれる本文９６４には、配送メールの宛先や、件名、送信日時など、送信者が配送メールを特定しやすい情報を記述する。また、返信メールを添付ファイルとしてボディ部９６３に含めるようにしてもよい。

以上説明したように、本実施形態のメールシステムによれば、承認者からの返信メールの宛先に、第１および第２の管理アドレスが含まれている場合には承認と判定し、返信メールの宛先に第１の管理アドレスのみが含まれている場合には非承認と判定することができる。一般的なＭＵＡでは、送信者（Reply-Toヘッダがある場合はそのメールアドレス、ない場合はFromヘッダのメールアドレス）にのみ返信する「返信」機能と、送信者と同報者（ToヘッダやCcヘッダのメールアドレス）のすべてに返信する「全員に返信」機能とが提供されているので、承認者は、一般的なＭＵＡを用いて、承認する場合には、承認依頼メールに対して「全員に返信」機能を用いて返信し、非承認とする場合には、承認依頼メールに対して「返信」機能を用いて返信すればよい。したがって、一般的なＭＵＡが備える「全員に返信」および「返信」の機能を利用して、承認者が承認および非承認の指定を容易に行うことができる。

なお、本実施形態では、返信メールに第１および第２の管理者アドレスの両方が含まれていた場合に承認と判定し、第１の管理者アドレスのみが含まれていた場合に非承認と判定するものとしたが、逆に、第１および第２の管理者アドレスの両方が含まれている場合に非承認と判定し、第１の管理者アドレスのみが含まれている場合に承認と判定するようにしてもよい。

また、本実施形態では、受信メールの配送に承認が必要であるか否かは、送信先がドメインユーザアドレスであるか否か、および、送信者に対応する承認者が登録されているか否かにより決定されるものとしたが、これに限らず、送信先のユーザごとに、承認が必要であるか否かを管理するテーブルを用意し、そのテーブルを参照して承認の要否を判定するようにしてもよいし、電子メールの内容に所定のキーワードが含まれているか否かにより判定するようにしてもよい。また、電子メールに添付ファイルが含まれているか否かなどにより判定するようにしてもよい。

また、本実施形態では、受信メールの配送に承認が必要であるか否かは、受信メールごとに判定するものとしたが、受信メールの宛先が複数ある場合には、受信者アドレスごとに承認が必要か否かを判定するようにしてもよい。この場合、受信者アドレスごとに、承認依頼メールが承認者に送信される。

また、本実施形態では、承認者テーブル１１２には送信者ごとに承認者が登録されるものとしたが、宛先になるメールアドレスに対する条件と、承認者アドレスとを対応付けて記憶しておき、受信メールの宛先にマッチする条件に対応する承認者に対して、承認依頼メールを送信するようにしてもよい。また、全ての受信メールについての承認依頼メールを所定の承認者に送信するようにしてもよい。

また、本実施形態では、配送メールはユーザ端末２０から送信されることを前提としたが、他のＭＴＡから受信し、他のドメイン宛に電子メールを転送する場合の電子メールの承認を行うようにしてもよい。

また、本実施形態のメールシステムでは、ＭＴＡの機能を提供するメールサーバ１０が受信メールの承認、非承認を判定するものとしたが、複数のＭＴＡの間で電子メールの中継を行う中継サーバが行うようにしてもよい。この場合のメールシステムの全体構成を図２５に示す。

図２５に示すように、中継サーバにおいて承認を行うメールシステムは、メールサーバ１６０と、複数の中継サーバ１５０および１７０とを含んで構成されている。
中継サーバ１５０および１７０はそれぞれ、上述したメールサーバ１０が備えていた、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３、送信待ちキュー１１４を備えており、制御部１０３、メール受付部１０４、およびメール送信部１０５に代えて、制御部１５１、メール受付部１５２、およびメール送信部１５３を備えている。

中継サーバ１５０および１７０のハードウェア構成は、図２に示すメールサーバ１０の構成と同じであり、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３および送信待ちキュー１１４も上述のメールサーバ１０と同じ機能を提供する。

中継サーバ１５０のメール受付部１５２は、メールサーバ１６０および中継サーバ１７０から電子メールを受信する。中継サーバ１５０のメール送信部１５３は、メールサーバ１６０から受信した電子メールは中継サーバ１７０に送信し、中継サーバ１７０から受信した電子メールはメールサーバ１６０に送信し、中継サーバ１５０が生成した電子メールはメールサーバ１６０に送信する。

また、中継サーバ１７０は、他の中継サーバまたはメールサーバ（不図示）とも接続されているものとし、中継サーバ１７０のメール受付部１５２は、他の中継サーバまたはメールサーバと中継サーバ１５０との両方から電子メールを受信する。中継サーバ１７０のメール送信部１５３は、中継サーバ１５０から受信した電子メールは他の中継サーバまたはメールサーバに送信し、他の中継サーバまたはメールサーバから受信した電子メールは中継サーバ１５０に送信する。

以下、中継サーバ１５０が備える制御部１５１、メール受付部１５２およびメール送信部１５３の動作を説明する。なお、中継サーバ１７０についても、電子メールの送信元や送信先が異なるものの動作は同じである。

メール受付部１５２は、メールサーバ１６０または中継サーバ１７０から送信される電子メールを受け付ける。メール受付部１５２は、電子メールを受け付けたことを制御部１５１に通知する。

制御部１５１は、メール受付部１５２からの通知が届くと、承認処理部１０６に取得した電子メールを渡し、承認処理部１０６が電子メールの承認、非承認を判定する。

メール送信部１５３は、承認処理部１０６により承認された配送メールを、配送メールの受信元に応じて、通信ネットワーク１４０を介して、中継サーバ１７０またはメールサーバ１６０に送信する。また、メール送信部１５３は、承認処理部１０６により生成された承認メールや非承認メール、エラーメールなどの電子メールを、通信ネットワーク１４０を介して、メールサーバ１６０に送信する。

このように、メールサーバ１０の機能を中継サーバが備えるようにすることもできる。これにより、数多くの電子メールを配送するメールサーバにおいて承認に係る処理負荷を上げることなく、電子メールの承認を行うことができる。

以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。

本実施形態の係るメールシステムの全体構成を示す図である。 本実施形態のメールシステムのハードウェア構成を示す図である。 本実施形態のメールシステムの機能構成を示す図である。 承認者テーブル１１２の構成例を示す図である。 受信メール９００の構成例を説明する図である。 送信待ちキュー１１４の構成例を示す図である。 承認待ちテーブル１１３に登録される承認待ち情報の構成例を示す図である。 監視処理部１０７による承認待ち情報の監視処理の流れを示す図である。 承認処理部１０６の詳細構成を示す図である。 受信メールの宛先に応じて、受信メールが承認者からの返信メールであるか否かを判定する処理の流れを示す図である。 受信メールがどのような電子メールであるのかを判定する処理の流れを示す図である。 受信メールに承認が必要か否かの判定を行う処理の流れを示す図である。 承認依頼メールの作成処理の流れを説明する図である。 承認依頼メール作成処理部２０２が作成する承認依頼メール９１０の構成例を示す図である。 エラー処理の流れを示す図である。 エラーメール９４０の構成例を示す図である。 非承認を表す返信メール９２０の構成例を示す図である。 承認を表す返信メール９３０の構成例を示す図である。 返信メールがどのようなメールであるのかを判定する処理の流れを示す図である。 返信メールに基づいて承認または非承認の判定を行う処理の流れを示す図である。 非承認処理の流れを示す図である。 非承認処理により作成される非承認メール９５０の構成例を示す図である。 承認処理の流れを示す図である。 承認処理において作成される承認メール９６０の構成例を示す図である。 中継サーバで承認、非承認の判定を行う場合のメールシステムの全体構成を示す図である。

符号の説明

１０ メールサーバ ２０ ユーザ端末
３０ 承認者端末 １０１ 主記憶装置
１０２ サーバプログラム １０３ 制御部
１０４ メール受付部 １０５ メール送信部
１０６ 承認処理部 １０７ 監視処理部
１０８ ＣＰＵ １０９ 通信インタフェース
１１０ ディスクインタフェース １１１ メールボックス
１１２ 承認者テーブル １１３ 承認待ちテーブル
１２１ 主記憶装置 １２２ クライアントプログラム
１２３ 制御部 １２４ メール表示部
１２５ メール受信部 １２６ メール送信部
１２７ ＣＰＵ １２８ 通信インタフェース
１２９ ディスクインタフェース １３０ 入出力インタフェース
１３１ メールデータ記憶部 １３２ 入出力装置
１４０ 通信ネットワーク １５０ 中継サーバ
１５１ 制御部 １５２ メール受付部
１５３ メール送信部 １６０ メールサーバ
１７０ 中継サーバ

Claims (10)

1. 電子メールの承認を行う情報処理装置であって、
   第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを電子メールの承認者に送信する承認依頼メール送信部と、
   前記承認依頼メールに対して前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、
   前記返信メールの宛先に前記第１および第２のメールアドレスの両方が含まれている場合、および前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合のいずれか一方の場合に承認と判定し、他方の場合に非承認と判定する承認判定部と、
   を備えることを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記承認者のメールアドレスを記憶する承認者記憶部と、
   電子メールを受信する電子メール受信部と、を備え、
   前記返信メール取得部は、前記電子メール受信部が受信した前記電子メールの送信元が前記承認者のメールアドレスと一致した場合に、当該電子メールを前記返信メールとすること、
   を特徴とする情報処理装置。
3. 請求項１に記載の情報処理装置であって、
   前記承認依頼メールを特定する電子メールＩＤに対応付けて、承認対象となる前記電子メールを記憶する電子メール記憶部と、
   前記返信メールの返信先の前記承認依頼メールを特定する前記電子メールＩＤを取得する返信先取得部と、
   前記承認判定部が承認と判定した場合にのみ、取得した前記電子メールＩＤに対応する前記電子メールを前記電子メール記憶部から読み出して送信する電子メール送信部と、
   を備えることを特徴とする情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記電子メール送信部は、前記承認判定部が非承認と判定した場合に、前記取得した電子メールＩＤに対応する前記電子メールを前記電子メール記憶部から削除すること、
   を特徴とする情報処理装置。
5. 請求項１に記載の情報処理装置であって、
   前記承認依頼メールを特定する電子メールＩＤに対応付けて、前記承認者のメールアドレスおよび前記電子メールを記憶する電子メール記憶部と、
   電子メールを受信する電子メール受信部と、
   前記電子メール受信部が受信した前記電子メールに、返信先の電子メールを特定する電子メールＩＤである返信先メールＩＤが含まれており、前記返信先メールＩＤに対応する前記メールアドレスおよび前記電子メールが前記電子メール記憶部に記憶されており、かつ、前記電子メール受信部が受信した前記電子メールの宛先に前記第１および第２のメールアドレスのいずれも含まれていない場合に、前記返信先メールＩＤに対応する前記メールアドレスを宛先として、エラーを示す情報を含む電子メールを送信するエラーメール送信部と、
   を備えることを特徴とする情報処理装置。
6. 請求項１に記載の情報処理装置であって、
   前記電子メールの送信元となるメールアドレスに対応付けて、前記承認者を特定する承認者特定情報を記憶する承認者記憶部と、
   前記電子メールを受信する電子メール受信部と、
   受信した前記電子メールの送信元に対応する前記承認者特定情報を前記承認者記憶部から読み出す承認者取得部と、
   を備え、
   前記承認依頼メール送信部は、前記承認依頼メールを、読み出した前記承認者特定情報により特定される前記承認者に送信すること、
   を特徴とする情報処理装置。
7. 請求項６に記載の情報処理装置であって、
   前記承認依頼メールを特定する電子メールＩＤに対応付けて、前記承認者特定情報および前記電子メールを記憶する電子メール記憶部と、
   前記電子メール受信部が受信した前記電子メールの宛先に前記第１のメールアドレスが含まれており、前記電子メール受信部が受信した前記電子メールの返信先の電子メールを特定する電子メールＩＤが含まれており、前記電子メール受信部が受信した前記電子メールに含まれる前記電子メールＩＤが前記電子メール記憶部に記憶されており、かつ、前記電子メール受信部が受信した前記電子メールの送信元が、前記電子メールＩＤに対応する前記承認者特定情報により特定される前記承認者でない場合に、当該承認者に対して不正なユーザから承認の回答を受信した旨を示す情報を含む電子メールを送信するエラーメール送信部と、
   を備えることを特徴とする情報処理装置。
8. 電子メールの送信元となるメールアドレスに対応付けて、前記電子メールの承認者を特定する承認者特定情報を記憶する承認者記憶部と、
   電子メールを受信する電子メール受信部と、
   前記電子メール受信部が受信した前記電子メールである受信メールの宛先に第１のメールアドレスが含まれているか否かにより、前記受信メールが前記承認者からの回答であるか否かを判定する承認回答判定部と、
   前記受信メールが前記承認者からの回答でないと判定した場合に、前記受信メールに承認が必要か否かを決定する承認要否決定部と、
   前記受信メールに承認が必要であると判定した場合に、前記受信メールの送信元に対応する前記承認者特定情報を前記承認者記憶部から取得する承認者取得部と、
   前記受信メールに承認が必要であると判定した場合に、前記第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを、取得した前記承認者特定情報により特定される前記承認者に送信する承認依頼メール送信部と、
   前記承認依頼メールを特定する電子メールＩＤおよび前記承認者特定情報に対応付けて、承認が必要であると判定した前記受信メールを、配送待ち電子メールとして記憶する配送メール記憶部と、
   前記配送メール記憶部を参照し、前記配送待ちメールが登録された日時から所定時間を経過したものを特定し、特定した前記配送待ちメールを削除するタイムアウト監視部と、
   前記受信メールが前記承認者からの回答であると判定された場合に、前記受信メールの返信先の電子メールを特定する電子メールＩＤである返信先メールＩＤを取得する返信先取得部と、
   前記返信先メールＩＤに対応する前記配送待ち電子メールが前記配送メール記憶部に記憶されていない場合に、前記受信メールの送信元を宛先として、エラーを表す情報を含む電子メールを送信する第１のエラー通知部と、
   前記返信先メールＩＤに対応する前記配送待ち電子メールが前記配送メール記憶部に記憶されており、かつ、前記返信先メールＩＤに対応する前記承認者特定情報により特定される前記承認者と前記受信メールの送信元とが一致しない場合に、エラーを表す情報を含む電子メールを前記承認者に送信する第２のエラー通知部と、
   前記返信先メールＩＤに対応する前記配送待ち電子メールが前記配送メール記憶部に記憶されている場合に、当該配送待ちメールについて、前記受信メールの宛先に前記第１および第２のメールアドレスが含まれているとき、および前記受信メールの宛先に前記第１のメールアドレスのみが含まれているときいずれか一方のときに承認と判定し、他方のときに非承認と判定する承認判定部と、
   前記配送待ちメールについて承認と判定した場合にのみ、前記配送待ちメールを配送する電子メール配送部と、
   を備えることを特徴とする情報処理装置。
9. 電子メールの承認を行う方法であって、
   情報処理装置が、
   第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを電子メールの承認者に送信し、
   前記承認依頼メールに対して前記承認者から返信された電子メールである返信メールを取得し、
   前記返信メールの宛先に前記第１および第２のメールアドレスの両方が含まれている場合、および前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合のいずれか一方の場合に承認と判定し、他方の場合に非承認と判定すること、
   を特徴とする承認方法。
10. 電子メールの承認を行うためのプログラムであって、
    コンピュータに、
    第１のメールアドレスを送信元とし、第２のメールアドレスを宛先として設定した電子メールである承認依頼メールを電子メールの承認者に送信するステップと、
    前記承認依頼メールに対して前記承認者から返信された電子メールである返信メールを取得するステップと、
    前記返信メールの宛先に前記第１および第２のメールアドレスの両方が含まれている場合、および前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合のいずれか一方の場合に承認と判定し、他方の場合に非承認と判定するステップと、
    を実行させるためのプログラム。

Images