(57)【特許請求の範囲】
【請求項１】
電子メールを受信する電子メール受信部を有する承認装置であり、
受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する承認依頼メール送信部と、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する承認判定部と、
を備えることを特徴とする承認装置。
【請求項２】
前記承認者の前記メールアドレスを記憶する承認者記憶部を備え、
前記返信メール取得部は、前記電子メール受信部が受信した前記電子メールの宛先が前記第１のメールアドレスと一致した場合に、当該電子メールを前記返信メールとして取得すること、
を特徴とする請求項１に記載の承認装置。
【請求項３】
前記承認依頼メールを特定する電子メールＩＤに対応付けて、承認対象となる前記電子メールを記憶する電子メール記憶部と、
前記返信メールに対応する前記承認依頼メールの前記電子メールＩＤを取得する返信先取得部と、
前記承認判定部が承認と判定した場合にのみ、取得した前記電子メールＩＤに対応する前記電子メールを前記電子メール記憶部から読み出して送信する電子メール送信部と、
を備えることを特徴とする請求項１に記載の承認装置。
【請求項４】
前記電子メール送信部は、前記承認判定部が非承認と判定した場合に、前記取得した電子メールＩＤに対応する前記電子メールを前記電子メール記憶部から削除すること、
を特徴とする請求項３に記載の承認装置。
【請求項５】
電子メールを受信する承認装置に、
受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信するステップ、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得するステップ、及び
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定するステップ
を実行させることを特徴とする承認方法。
【請求項６】
電子メールを受信する承認装置に、
受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する機能、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する機能、及び
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する機能
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、承認装置、承認方法、及びプログラムに関する。
【背景技術】
【０００２】
情報伝達の手段として電子メールが普及している。電子メールにどのような内容を記載するかは送信者の責任であり、送信者の勘違いや操作ミスによって、例えば社外秘情報などの情報が受信者に送信されると情報漏洩につながる。そこで、電子メールの送信前に承認者による承認が行われている（特許文献１および２参照）。
【特許文献１】特開２００７−６５７８７号公報
【特許文献２】特開２００５−３４６６４３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に開示される技術では、承認者に承認を行うように電子メールが送信されるが、承認者は、その電子メールに記載されたＵＲＬにＷｅｂブラウザを操作してアクセスし、Ｗｅｂブラウザを操作して承認を行う必要があるので手間がかかる。また、特許文献２に開示される技術では、承認者は、承認要請メールデータを受信し、それを所定の承認用または否認用のメールアドレスに転送することによって承認を行うことができるが、転送先として所定の承認用または否認用のメールアドレスを選択する手間がかかる。
【０００４】
本発明は、このような背景を鑑みてなされたものであり、承認者が容易に電子メールの承認を行うことができる承認装置、承認方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するための本発明の主たる発明は、電子メールを受信する電子メール受信部を有する承認装置であり、受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する承認依頼メール送信部と、前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する承認判定部とを備えることとする。  
【０００６】
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
【発明の効果】
【０００７】
本発明によれば、承認者が容易に電子メールの承認を行うことができる。
【発明を実施するための最良の形態】
【０００８】
＝＝システム構成＝＝
以下、本発明の一実施形態に係る電子メールを送信するメールシステムについて説明する。本実施形態のメールシステムでは、電子メールの送信時に、電子メールの送信者とは異なる承認者からの承認を受けることを想定している。
【０００９】
図１は、本実施形態の係るメールシステムの全体構成を示す図である。同図に示すように、本実施形態のメールシステムは、メールサーバ１０、ユーザ端末２０、および承認者端末３０を含んで構成されている。ユーザ端末２０、承認者端末３０、およびメールサーバ１０はそれぞれ通信ネットワーク１４０に接続されており、通信ネットワーク１４０を介して互いに通信が可能である。通信ネットワーク１４０は、例えば、インターネットやＬＡＮ（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ヘッダのメールアドレス）のすべてに返信する「全員に返信」機能とが提供されているので、承認者は、一般的なＭＵＡを用いて、承認する場合には、承認依頼メールに対して「全員に返信」機能を用いて返信し、非承認とする場合には、承認依頼メールに対して「返信」機能を用いて返信すればよい。したがって、一般的なＭＵＡが備える「全員に返信」および「返信」の機能を利用して、承認者が承認および非承認の指定を容易に行うことができる。
【０１０８】
なお、本実施形態では、返信メールに第１および第２の管理者アドレスの両方が含まれていた場合に承認と判定し、第１の管理者アドレスのみが含まれていた場合に非承認と判定するものとしたが、逆に、第１および第２の管理者アドレスの両方が含まれている場合に非承認と判定し、第１の管理者アドレスのみが含まれている場合に承認と判定するようにしてもよい。
【０１０９】
また、本実施形態では、受信メールの配送に承認が必要であるか否かは、送信先がドメインユーザアドレスであるか否か、および、送信者に対応する承認者が登録されているか否かにより決定されるものとしたが、これに限らず、送信先のユーザごとに、承認が必要であるか否かを管理するテーブルを用意し、そのテーブルを参照して承認の要否を判定するようにしてもよいし、電子メールの内容に所定のキーワードが含まれているか否かにより判定するようにしてもよい。また、電子メールに添付ファイルが含まれているか否かなどにより判定するようにしてもよい。
【０１１０】
また、本実施形態では、受信メールの配送に承認が必要であるか否かは、受信メールごとに判定するものとしたが、受信メールの宛先が複数ある場合には、受信者アドレスごとに承認が必要か否かを判定するようにしてもよい。この場合、受信者アドレスごとに、承認依頼メールが承認者に送信される。
【０１１１】
また、本実施形態では、承認者テーブル１１２には送信者ごとに承認者が登録されるものとしたが、宛先になるメールアドレスに対する条件と、承認者アドレスとを対応付けて記憶しておき、受信メールの宛先にマッチする条件に対応する承認者に対して、承認依頼メールを送信するようにしてもよい。また、全ての受信メールについての承認依頼メールを所定の承認者に送信するようにしてもよい。
【０１１２】
また、本実施形態では、配送メールはユーザ端末２０から送信されることを前提としたが、他のＭＴＡから受信し、他のドメイン宛に電子メールを転送する場合の電子メールの承認を行うようにしてもよい。
【０１１３】
また、本実施形態のメールシステムでは、ＭＴＡの機能を提供するメールサーバ１０が受信メールの承認、非承認を判定するものとしたが、複数のＭＴＡの間で電子メールの中継を行う中継サーバが行うようにしてもよい。この場合のメールシステムの全体構成を図２５に示す。
【０１１４】
図２５に示すように、中継サーバにおいて承認を行うメールシステムは、メールサーバ１６０と、複数の中継サーバ１５０および１７０とを含んで構成されている。  
中継サーバ１５０および１７０はそれぞれ、上述したメールサーバ１０が備えていた、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３、送信待ちキュー１１４を備えており、制御部１０３、メール受付部１０４、およびメール送信部１０５に代えて、制御部１５１、メール受付部１５２、およびメール送信部１５３を備えている。
【０１１５】
中継サーバ１５０および１７０のハードウェア構成は、図２に示すメールサーバ１０の構成と同じであり、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３および送信待ちキュー１１４も上述のメールサーバ１０と同じ機能を提供する。
【０１１６】
中継サーバ１５０のメール受付部１５２は、メールサーバ１６０および中継サーバ１７０から電子メールを受信する。中継サーバ１５０のメール送信部１５３は、メールサーバ１６０から受信した電子メールは中継サーバ１７０に送信し、中継サーバ１７０から受信した電子メールはメールサーバ１６０に送信し、中継サーバ１５０が生成した電子メールはメールサーバ１６０に送信する。
【０１１７】
また、中継サーバ１７０は、他の中継サーバまたはメールサーバ（不図示）とも接続されているものとし、中継サーバ１７０のメール受付部１５２は、他の中継サーバまたはメールサーバと中継サーバ１５０との両方から電子メールを受信する。中継サーバ１７０のメール送信部１５３は、中継サーバ１５０から受信した電子メールは他の中継サーバまたはメールサーバに送信し、他の中継サーバまたはメールサーバから受信した電子メールは中継サーバ１５０に送信する。
【０１１８】
以下、中継サーバ１５０が備える制御部１５１、メール受付部１５２およびメール送信部１５３の動作を説明する。なお、中継サーバ１７０についても、電子メールの送信元や送信先が異なるものの動作は同じである。
【０１１９】
メール受付部１５２は、メールサーバ１６０または中継サーバ１７０から送信される電子メールを受け付ける。メール受付部１５２は、電子メールを受け付けたことを制御部１５１に通知する。
【０１２０】
制御部１５１は、メール受付部１５２からの通知が届くと、承認処理部１０６に取得した電子メールを渡し、承認処理部１０６が電子メールの承認、非承認を判定する。
【０１２１】
メール送信部１５３は、承認処理部１０６により承認された配送メールを、配送メールの受信元に応じて、通信ネットワーク１４０を介して、中継サーバ１７０またはメールサーバ１６０に送信する。また、メール送信部１５３は、承認処理部１０６により生成された承認メールや非承認メール、エラーメールなどの電子メールを、通信ネットワーク１４０を介して、メールサーバ１６０に送信する。
【０１２２】
このように、メールサーバ１０の機能を中継サーバが備えるようにすることもできる。これにより、数多くの電子メールを配送するメールサーバにおいて承認に係る処理負荷を上げることなく、電子メールの承認を行うことができる。
【０１２３】
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
【図面の簡単な説明】
【０１２４】
【図１】本実施形態の係るメールシステムの全体構成を示す図である。
【図２】本実施形態のメールシステムのハードウェア構成を示す図である。
【図３】本実施形態のメールシステムの機能構成を示す図である。
【図４】承認者テーブル１１２の構成例を示す図である。
【図５】受信メール９００の構成例を説明する図である。
【図６】送信待ちキュー１１４の構成例を示す図である。
【図７】承認待ちテーブル１１３に登録される承認待ち情報の構成例を示す図である。
【図８】監視処理部１０７による承認待ち情報の監視処理の流れを示す図である。
【図９】承認処理部１０６の詳細構成を示す図である。
【図１０】受信メールの宛先に応じて、受信メールが承認者からの返信メールであるか否かを判定する処理の流れを示す図である。
【図１１】受信メールがどのような電子メールであるのかを判定する処理の流れを示す図である。
【図１２】受信メールに承認が必要か否かの判定を行う処理の流れを示す図である。
【図１３】承認依頼メールの作成処理の流れを説明する図である。
【図１４】承認依頼メール作成処理部２０２が作成する承認依頼メール９１０の構成例を示す図である。
【図１５】エラー処理の流れを示す図である。
【図１６】エラーメール９４０の構成例を示す図である。
【図１７】非承認を表す返信メール９２０の構成例を示す図である。
【図１８】承認を表す返信メール９３０の構成例を示す図である。
【図１９】返信メールがどのようなメールであるのかを判定する処理の流れを示す図である。
【図２０】返信メールに基づいて承認または非承認の判定を行う処理の流れを示す図である。
【図２１】非承認処理の流れを示す図である。
【図２２】非承認処理により作成される非承認メール９５０の構成例を示す図である。
【図２３】承認処理の流れを示す図である。
【図２４】承認処理において作成される承認メール９６０の構成例を示す図である。
【図２５】中継サーバで承認、非承認の判定を行う場合のメールシステムの全体構成を示す図である。
【符号の説明】
【０１２５】
１０    メールサーバ                      ２０    ユーザ端末
３０    承認者端末                        １０１  主記憶装置
１０２  サーバプログラム                  １０３  制御部
１０４  メール受付部                      １０５  メール送信部
１０６  承認処理部                        １０７  監視処理部
１０８  ＣＰＵ                            １０９  通信インタフェース
１１０  ディスクインタフェース            １１１  メールボックス
１１２  承認者テーブル                    １１３  承認待ちテーブル
１２１  主記憶装置                        １２２  クライアントプログラム
１２３  制御部                            １２４  メール表示部
１２５  メール受信部                      １２６  メール送信部
１２７  ＣＰＵ                            １２８  通信インタフェース
１２９  ディスクインタフェース            １３０  入出力インタフェース
１３１  メールデータ記憶部                １３２  入出力装置
１４０  通信ネットワーク                  １５０  中継サーバ
１５１  制御部                            １５２  メール受付部
１５３  メール送信部                      １６０  メールサーバ
１７０  中継サーバ
【図１】
0004857246.tif 000002
【図２】
0004857246.tif 000003
【図３】
0004857246.tif 000004
【図４】
0004857246.tif 000005
【図５】
0004857246.tif 000006
【図６】
0004857246.tif 000007
【図７】
0004857246.tif 000008
【図８】
0004857246.tif 000009
【図９】
0004857246.tif 000010
【図１０】
0004857246.tif 000011
【図１１】
0004857246.tif 000012
【図１２】
0004857246.tif 000013
【図１３】
0004857246.tif 000014
【図１４】
0004857246.tif 000015
【図１５】
0004857246.tif 000016
【図１６】
0004857246.tif 000017
【図１７】
0004857246.tif 000018
【図１８】
0004857246.tif 000019
【図１９】
0004857246.tif 000020
【図２０】
0004857246.tif 000021
【図２１】
0004857246.tif 000022
【図２２】
0004857246.tif 000023
【図２３】
0004857246.tif 000024
【図２４】
0004857246.tif 000025
【図２５】
0004857246.tif 000026