内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備えることを特徴とする電子メール保留システム。前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることを特徴とする請求項1に記載の電子メール保留システム。前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることを特徴とする請求項1または2に記載の電子メール保留システム。内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行することを特徴とする電子メール保留方法。前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することを特徴とする請求項4に記載の電子メール保留方法。前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することを特徴とする請求項4または5に記載の電子メール保留方法。しかしながら、特許文献1に開示された技術は、電子メール本文に関する監査のみであり、電子メールに添付されたファイルの内容までは考慮されていないため、メール本文に規制語句がなければ添付ファイルの内容が営業秘密であっても送信者に警告されることなく外部へ送信されてしまうという問題がある。様々な文書を電子ファイルで管理することが多い企業の実情からすると、電子メールに添付したファイルの内容まで監査できなければ適切な情報漏洩防止を図ることはできない。一方、特許文献2に開示された技術では、添付ファイルの内容まで監査対象としているが、ファイルは平文で添付されることを前提としている。したがって、暗号化された添付ファイルが送信された場合には添付ファイルからポリシーを読み取れず、毎回電子メール送信者への問い合わせが発生することになり、送信者の負担は大きい。また、近年では、電子メール送信途中での情報漏えいを防止する観点からも、企業間のデータのやり取りでは、添付ファイルの暗号化は一般的に実施されているものであるため、暗号化した添付ファイルも適切に監査可能とすることが求められる。本発明は、これらの課題を解決し、電子メールの添付ファイルが暗号化されている場合であっても、その内容を適切に監査可能とする電子メール保留システム及び方法を提供することを目的とする。上記の目的を達成するために、本発明は、以下の構成を提供する。本発明の第1の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備える。上記システムにおいて、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることが、好適である。上記システムにおいて、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることが、好適である。本発明の第2の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行する。上記方法において、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することが、好適である。上記方法において、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することが、好適である。以上のように構成された本発明によれば、電子メールの添付ファイルが暗号化されている場合であっても、その復号鍵を電子メール送信システム上で自動的にトラッキングして復号することができ、暗号化されたファイルであってもその内容を監査可能にし、情報漏洩をより実効的に防止することができる。以下、本発明の実施例を示した図面を参照して実施形態を説明する。図1は、本発明に係る電子メール保留システムのシステム構成図である。なお、明細書及び図面中メールと記載している場合、特に説明がない限り電子メールを意味する。電子メール保留システムは、内部クライアント1、メール保留サーバ2、メールサーバ4、ルータ6、および外部クライアント5の各装置を、有線又は無線の通信回線により通信可能に接続したシステムである。各装置は1台ずつ図示しているが、それぞれ2以上存在していてもよい。また、各装置はそれぞれ1台ずつ存在する必要はなく、例えば、1台の装置が、メール保留サーバ2とメールサーバ4の両方の機能を備えるように構成することも可能である。図1において、内部クライアント1、メール保留サーバ2、メールサーバ4、およびルータ6はLANLocalAreaNetwork7によって互いに通信可能に接続されている。接続方法はLANに限定されるものではなく、互いに通信可能に接続されていればよい。また、図1においては、外部クライアント5がインターネット8によってLAN7と接続されているが、例えば、外部クライアント5がLAN7とは別のLANに接続されており、ルータ6がこれらのLAN同士を接続していても構わない。内部クライアント1及び外部クライアント5は、メール送受信手段11、51を有する。これらはメール送受信プログラムであり、例えばOUTLOOK登録商標のような、いわゆるメーラソフトである。また、両クライアントはそれぞれ、入力装置18、表示装置19を備えている。メール保留サーバ2は、内部クライアント1から送信されたメールの保留処理と、暗号化された添付ファイルの復号処理を実施する。以下、メール保留サーバ2が有する各手段について説明する。メール送受信手段21は、例えばSendmail登録商標等の、いわゆるSMTPSimpleMailTransferProtocolサーバソフトであり、メールを送受信する機能を有している。メール保留判定手段22は、メール送受信手段21がメールを受信した場合に、メール送受信手段21によって起動され、受信したメールを所定時間保留する必要があるか否かを判定し、保留する必要があるメールを保留メールデータベースDB32に記憶し、保留する必要がないメールは、直ちにメールサーバ4に送信する。すなわち、メール保留判定手段22は、メール送受信手段21の機能の一部を代替する。保留メール送信手段23は、いわゆるデーモンソフトであり、メール保留サーバ2によりより正確にはメール保留サーバ2のオペレーティングシステムにより所定の時間間隔で継続的に起動される。保留メール送信手段23は、保留メールDB32に記憶された各メールについて、保留時間を経過したか否かを判定し、保留時間が経過したメールをメールサーバ4に送信する。そして、メールサーバ4に送信したメールすなわち保留時間が経過したメールを保留メールDB32から削除する。暗号メール判断手段24は、メール送受信手段21がメールを受信した場合に、メール送受信手段21によって起動され、受信したメールの添付ファイルが暗号化されているか否かを判断する処理である。この判断は、添付ファイルのファイル形式に基づいて行われる。暗号化判断可能なファイル形式については、MicrosoftOffice登録商標製品の読み取りパスワードの設定、PDFのパスワード設定、パスワードZIPなど一般的な形式のものから、秘文登録商標暗号化形式などの独自形式まで、いずれのファイル形式であってもよい。一般的なファイル形式の暗号化判断に関しては、ツール等による判断が可能である。独自形式の暗号化判断に関しては、その形式ごとの暗号化判断プログラム、ツール等を利用する。復号鍵取得手段25は、メール送受信手段21がメールを受信した場合に、メール送受信手段21によって起動され、受信したメールが復号鍵通知メールであるか否か、すなわちメール本文内に復号鍵が含まれているか否かを判断し、復号鍵が含まれていると判断した場合はその復号鍵を取得して復号鍵候補とするとともに、復号鍵DB31に登録する。暗号メール復号手段26は、いわゆるデーモンソフトであり、メール保留サーバ2によりより正確にはメール保留サーバ2のオペレーティングシステムにより所定の時間間隔で継続的に起動される。暗号メール復号手段26は、メール保留サーバ上にて復号鍵待ちで保留されているメール毎に、例えば、対応する復号鍵を復号鍵DB31より抽出して復号鍵候補とし、復号化を試みる。復号化に成功すれば、暗号化メールの復号鍵待ち保留状態を解除する。復号不可または復号鍵候補がない場合は、まだ復号鍵通知メールがメール保留サーバに到達していないものと判断し、そのまま終了する。復号鍵要求手段27は、いわゆるデーモンソフトであり、メール保留サーバ2によりより正確にはメール保留サーバ2のオペレーティングシステムにより所定の時間間隔で継続的に起動される。復号鍵要求手段27は、所定時間以上、復号鍵通知メール待ちのままとなった暗号化メール毎に、その送信者に対して復号鍵をメール保留サーバに連絡するよう促す復号鍵要求メールを作成し、メール保留サーバ2上のメール送信手段21にて暗号化メールの送信者に復号鍵要求メールを送信する。メール保留サーバ2は、保留メールDB32と復号鍵DB31を有する記憶装置3と、入力装置28、表示装置29と接続されている。保留メールDB32には、所定時間だけ保留した後に送信すべきメールが記憶されており、メール保留判定手段23によって保留が必要と判断されるとそのメールに関する情報が追加される。そして、所定の保留時間を経過した場合や上長によるそのメールの送信承認がなされた場合など、所定の条件を満たした場合はメールの保留が解除されるので、そのメールに関する情報が削除される。復号鍵DB31は、復号鍵通知メールから取得した復号鍵を格納し、暗号メール復号手段26に対して復号鍵候補を提供する。メールから復号鍵を検出するとその復号鍵に関する情報が追加される。メールサーバ4はPC等の装置であり、メール送受信手段41メール送受信プログラムを備えている。メール送受信手段41は、メール送受信手段21と同様、SMTPサーバソフトである。ルータ6は、LAN7に接続された装置以外の宛先に送信されるメールを、インターネット8に送信する。逆に、このような機能を備えている装置であればよく、必ずしもルータである必要はない。インターネット8に送信されたメールは、図示していないが各種通信装置を経由して送信先例えば外部クライアント5が受信する。図2は、保留メールDB32のデータ構成図である。保留メールレコード210は、保留メールID211、保留開始時212、保留時間213、保留メール214及び保留ステータス215のデータ項目から構成される。保留対象となったメール毎に、1つの保留メールレコード210が作成される。保留メールID211は、保留メールレコード210を一意に識別するための識別情報である。保留開始時刻212には、例えば200804281315042008年4月28日13時15分4秒といったように、保留メールレコード210を追加する際の時刻が設定される。保留時間213には、例えば0015000時間15分0秒といったように、保留メールレコード210の保留を継続する時間が設定される。保留メール送信手段23は、保留開始時刻212とシステム時刻を比較し、保留時間213が経過した場合に、保留メール214を送信する。保留メール214は、保留しているメールに内容が設定される。具体的には図3を用いて説明する。保留ステータス215は、そのメールの処理状況が設定される。例えば、所定の保留時間が経過する間メール送信を保留している場合は一時保留中、上長によるメール送信の承認を待つための保留の場合は上長承認待ち等、所定の条件を満たすまで外部クライアントへの送信を保留する保留状態となり、復号鍵を検出するために保留している場合は復号鍵待ちの保留状態となる。なお、保留時間213は、メールの宛先と保留ステータスごとに保留時間を予め指定したテーブルを参照して設定する方法、または全てのメールに対して同じ保留時間を設定する方法のいずれを用いてもよい。図3は、図2の保留メールDB32の中の保留メール214のデータ構成図である。保留メール214は、メールエンベロープ315、メールヘッダ316、および本文317から構成される。本文317は、内部クライアント1を操作する送信者が入力したメールの本文、およびメールに添付したファイルからなる。また、メールヘッダ316は、送信者が入力したメールの宛先、タイトル等を、メール送受信手段21が編集した結果データからなる。すなわち、メールヘッダ316、および本文317は、内部クライアント1がメール保留サーバ2に送信したメールの内容である。メールエンベロープ315は、メールの送信元mailfromと、1以上の宛先rcpttoから構成され、メール保留判定手段22が受信したメールから作成する。内部クライアント1を操作する送信者は、宛先としてメーリングリストのアドレス等、実際の宛先とは異なる宛先を入力する場合がある。そこで、メール保留判定手段22は、メールを受信すると、メールに設定されている送信者が入力した宛先を実際の宛先に変換して宛先rcpttoを作成する。そして、送信元mailfromと宛先rcpttoをメールエンベロープ315としてメールに追加する。図4は、復号鍵DB31のデータ構成図である。復号鍵レコード410は、登録日411、復号鍵412、通知件名413、通知送信者ヘッダ414、通知宛先415、通知宛先ヘッダ416、復号成功回数417及び最終復号日時418のデータ項目から構成される。登録日411は、復号鍵取得手段25により復号鍵を取得して復号鍵DB31に登録した日、復号鍵412はパスワード等の鍵の内容である。通知件名413は復号鍵を取得したメールの件名、通知送信者ヘッダ414と通知宛先ヘッダ416は復号鍵を取得したメールのメールヘッダ316に含まれているメール送信者とメール宛先の電子メールアドレス、通知宛先415は、復号鍵を取得したメールの図3に示したエンベロープ315に含まれるメール宛先の電子メールアドレスである。さらに、復号成功回数417は、その復号鍵を用いて暗号化ファイルの復号に成功した回数、最終復号日時418は、最後にその復号鍵を用いて暗号化ファイルを復号した日時を意味する。このように復号鍵を登録しておくことで、暗号化された送信メールをアーカイブしても、監査したいタイミングで復号化されたデータを確認できるため、アーカイブデータとしての有用性も高まる。なお、復号鍵DB31は蓄積型であるが、復号鍵レコード410の復号成功回数417や最終復号日時418の情報から今後利用される可能性の低い復号鍵レコード410の除去を定期的に行ってもよい。図5は、図1のメール保留サーバ2における暗号化メール処理フローである。以下の説明においては、図1~図4中の符号を適宜参照する。内部クライアント1から外部クライアント5に送信した電子メールはメール保留サーバ2にて受信されステップ501、暗号メール判断手段24によってその電子メールの添付ファイルが暗号化されているか否かすなわち暗号化電子メールであるか非暗号化電子メールであるかを判断するステップ502。非暗号化電子メールであれば、非暗号化電子メールの保留状態である一時保留中や上長承認待ち等を保留ステータス215として保留メールDB32にその電子メールに関する情報を登録する。同時に保留時間経過待ちまたは上長承認待ち処理等、所定の条件を満たすまで外部クライアントへの送信を保留する待ち処理へ移行する。この場合は、送信者が設定した保留時間経過または上長が承認した時点で、外部クライアント5宛に電子メールが送信される。または、電子メール送信システム上であらかじめ定められたセキュリティポリシにより、メールの内容によってはメール送信がキャンセルされる。ステップ502において、暗号化電子メールであると判断すると、復号鍵を取得するために、その暗号化電子メールは所定時間の間、メール保留サーバ2上に保留される。この場合、保留ステータス215を復号鍵待ち保留状態に設定して、その他の電子メールに関する情報とともに保留メールDB32に登録されるステップ503。メール保留サーバ2は、所定時間、メール保留サーバ2を経由する外部クライアント5宛の電子メールについて、復号鍵通知メールの有無を監視する。送信者が手動で設定したパスワード等の復号鍵は、通常、暗号化電子メールとは別に、後から電子メールで通知することが多いためである。メール保留サーバ2は、復号鍵通知メールを検出すると、その復号鍵通知メールに含まれる復号鍵を復号鍵候補として取得し、取得した復号鍵候補を用いて、保留ステータス215が復号鍵待ち保留状態となっている暗号化電子メールの暗号化添付ファイルの復号処理を試み、復号が可能か否かを判断するステップ507。復号不能の場合復号鍵が正しくない場合は、再び復号鍵通知メールを監視する。なお、復号鍵通知メールを監視する所定時間が経過したか否かを計時しステップ505、所定時間経過しても復号鍵候補を取得できない場合は復号を断念し、復号鍵待ち保留状態の対象の暗号化電子メールをメール保留サーバ2から削除し、保留メールDB32からも該当保留メールレコード210を削除する。さらに、暗号化された添付ファイルの内容を監査できないためメール送信できない旨を、メール保留サーバ2から復号鍵待ち保留状態の対象の暗号化電子メールの送信者に通知するステップ511。ステップ507において、取得した復号鍵候補を用いて暗号化添付ファイルを正しく復号できた場合は、その復号鍵を復号鍵DB31に登録し、暗号化添付ファイルの平文データを保留対象の電子メールとするステップ509。そして、保留ステータス215の復号鍵待ちの設定を解除し、非暗号化電子メールと同様の一時保留中又は上長承認待ち等に設定し、保留時間経過待ちまたは上長承認待ち処理へ移行する。すなわち、所定の条件を満たすまで送信を保留する待ち状態に移行する。これにより、例えば上長承認が必要とされる電子メールの場合、上長は添付ファイルの内容まで確認したうえで外部クライアント5等への電子メール送信の可否を判断できるため、実効的な情報漏洩の防止が可能である。そして、電子メール送信者から別途上長に対してパスワード等の復号鍵情報を送付する必要がないため、電子メール送信者の負担も軽減できる。図6は、図5のメール保留サーバ2における復号鍵候補の取得処理フロー504の詳細フローである。メール保留サーバ2は、自身に送信されてくる電子メールが復号鍵を有するか否かをチェックするステップ601。電子メールから復号鍵を検出する方法の1つとして、メール本文内にある復号鍵を示唆するキーワードに基づいて検出する方法がある。具体的には、パスワード、Password、Pass等の語句をキーワードとして、このようなキーワードがメール本文中に記載されていた場合、その前後の文章から半角英数の文字列を抽出して復号鍵候補とする。また、:や;等の区切り記号をキーワードとして、その直後に半角英数の文字列が続いている場合はそれを復号鍵候補として抽出することも考えられる。その他の復号鍵を検出する方法としては、復号鍵を相手方に通知する場合は、暗号化した添付ファイルを送付した電子メールに返信する形で通知することが多いため、保留対象の電子メールに対する返信メールや転送メールが送信された場合は、その電子メールにおいて新規に追記された部分に着目して半角英数の文字列を抽出することも考えられる。このような復号鍵検出を効率よく実施するために、パスワードの性質を利用することも考えられる。例えば、パスワードの多くは半角英数で3文字程度から長くても20文字程度で構成され、間に空白は含まないため、前述のようにキーワードに基づいて取得した復号鍵候補に対しパスワードの性質に一致するか否かによりフィルタリングすることで、通常の英文との混同を回避できる。また、パスワードの性質を会社内で定めている場合は、その性質を利用してフィルタリングをかければより効率よくパスワードを取得できる。さらに、メール本文中にパスワードはいつもの形式ですというようなセンテンスを検出した場合は、この電子メールの送信者や宛先、件名と、復号鍵DB31に登録された各復号鍵レコード410の通知件名413、通知送信者ヘッダ414、通知宛先ヘッダ416、通知宛先エンベロープ415を照らし合わせ、復号鍵候補を抽出することも可能である。復号鍵通知メールと思われる電子メールを検出した場合、そのメール本文より復号鍵を取得し、復号鍵候補の取得処理を終了する。復号鍵通知メールを検出できない場合は、所定時間が経過するまで復号鍵候補を有する電子メールを待つステップ602、ステップ603。復号鍵が取得できないままで所定時間が経過した場合は、復号鍵の送信を求める催促メールを、復号鍵待ち保留状態の対象電子メールの送信者に送信しステップ602、ステップ604、送信者から復号鍵が通知されるのを待つ。メール保留サーバ2は、自身宛てに送信されてくる電子メールが復号鍵を有するかチェックするステップ606。復号鍵通知メールと思われる電子メールを検知した場合はそのメール本文より復号鍵を取得して復号鍵取得処理を終了する。一方で、送信者から復号鍵を通知するメールが所定時間経過しても送られてこない場合は復号鍵待ちを断念し、タイムアウトしたとして復号鍵候補の取得処理を終了する。なお、本実施例では暗号化された添付ファイルを正常に復号できた復号鍵のみを復号鍵DB31に登録するものとして記載したが、復号鍵候補の取得処理において復号鍵候補として検出したものは一律に復号鍵DB31に登録するようにしてもよい。このような場合、不要な復号鍵レコード410が累積的に蓄積しやすいので、登録日411から一定期間経過し、かつ復号成功回数417が0回のままの復号鍵候補や、最終復号日時418から一定期間を経過した復号鍵候補がないか定期的にチェックし、復号鍵DB31を定期的に整理する方が適切である。さらに、本実施例では個々の復号鍵待ち保留状態の電子メールに対して復号鍵を取得する時間を設ける処理を記載したが、メール通信プロトコル実装上、復号鍵通知メールが暗号化電子メールよりも先にメール保留サーバ2に到達する可能性もあるため、復号鍵待ち保留状態の電子メール毎に復号鍵通知メールを監視するのではなく、メール保留サーバに到達した全ての電子メールに対して、復号鍵が格納されていないか検査を行う方がより適切である。また、復号鍵候補を取得する方法については他の方法も考えられる。パスワード等の復号鍵はプロジェクトとして過去のものを使いまわすことが多い。例えば、最初にある復号鍵を決めておき、その後はそのプロジェクト内では同じ復号鍵を用いることをルールとするような場合である。したがって、暗号化されたファイルが添付されている電子メールの件名や本文からプロジェクト名を推定し、復号鍵DB31の通知件名413等の情報からプロジェクト名が一致するものを探し、その復号鍵を復号鍵候補としてもよい。この場合、復号鍵候補の取得処理においては、復号鍵が付された電子メールからプロジェクト名を推測し、復号鍵DB31に登録しておく方がより効率的と考えられる。さらに、電子メール以外例えば電話やFAX等で復号鍵をやり取りしている場合には、復号鍵通知メールがメール保留サーバ2を経由しない。このようなケースに対応するため、復号鍵通知メール取得のため所定時間以上経過した保留メールに対して、メール保留サーバ2はメール送信者に対して、復号鍵要求メールを送信する手段を設けることも可能である。復号鍵要求メールを受け取った当該保留メールの送信者は、その復号鍵要求メールに対する返信メールのメール本文に復号鍵を記載してメール保留サーバ2に返信する。この場合、復号鍵DB31に、復号鍵文字列、日付、送信者、宛先、件名として格納しておくことで、前述の復号鍵候補の検出に用いることができ、毎回暗号化電子メールが送信されるたびに送信者に対して復号鍵の要求を行わなくてもすむ可能性が高くなる。さらに、所定時間以上経過した保留メールに対する復号鍵の特定は、復号鍵DB31に登録されている複数の復号鍵を順次適用して行ってもよい。この場合、復号鍵レコード410の復号成功回数417から、過去に正常復号できた実績のある復号鍵を優先的に使用して、添付ファイルの復号を試みるようにしてもよい。また復号鍵として日付を含んだ形式であると判断できる場合は、メール送信日時の値を変換して復号鍵とすることも考えられる。以上、本実施形態について説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。例えば、上記実施形態では、電子メールにファイルを添付する際に添付ファイルの検査を行ったが、電子メールが送信されるまでの任意のタイミングで検査を行って良い。その他、上記実施形態に、種々の変更または改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。