メール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラム
【課題】汎用性、安全性及び利便性が向上したメール誤配信防止装置を提供する。
【解決手段】承認者に承認依頼メールを送信する手段と前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールが所定の条件を満たす場合には、対象となっているメールの配信を承認する手段と、を備え、承認依頼メールには、承認キーワードを含め、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワードが含まれていなければ、対象となっているメールの配信を禁止する手段を更に備える。
【解決手段】承認者に承認依頼メールを送信する手段と前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールが所定の条件を満たす場合には、対象となっているメールの配信を承認する手段と、を備え、承認依頼メールには、承認キーワードを含め、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワードが含まれていなければ、対象となっているメールの配信を禁止する手段を更に備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機密情報等を含む等の理由により、外部に送信されてはならないメールが誤って外部に送信されることを防止するためのメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラムに関する。
【背景技術】
【０００２】
通常、電子メールの誤配信を防止するために、一時保留した送信メールの承認を送信者自身や第三者により行ってから外部に配信する仕組みは存在していたが、送信を承認するためには専用のWebシステムやクライアントを使用して承認手続きを行う方法が主流である。
【０００３】
通常は、特開２００９−１１８１７４号公報「情報処理装置、承認方法、およびプログラム」（特許文献１）のように、誤配信防止のための第三者承認手続きをユーザのメールクライアントから実施する方式は知られていたが、クライアントから送信するメールにはReferencesヘッダやIn-Reply-Toヘッダが付与されている必要があり、さらに承認回答にはメールクライアントの「全員に返信」機能を使用するため、前記ヘッダが付与されないメールクライアントや、「全員に返信」機能が備わっていないメールクライアントでは対応できない問題があった（汎用性の問題）。
【０００４】
また、承認と禁止の判断には依頼回答メールの宛先メールアドレスを使用して区別するため、承認者が承認と禁止との間の誤りを起こしやすい問題や、Referenceヘッダには複数のメールＩＤが指定されていることもあり、依頼回答メールは必ずしも承認対象のメールを一意に特定するものではないという問題があった（安全性の問題）。
【０００５】
さらに、ある承認対象メールに対する承認依頼メールと承認結果通知メールの関連付けができないため、承認依頼が多数になってくると承認漏れや確認のための手間が必要となる問題があった（利便性の問題）。
【０００６】
また、特開２０１０−１１４３５号公報「電子メール保留システム」（特許文献２）も知られているが、この技術では専用のクライアントソフトを使用するため、汎用のメールクライアントソフトでは対応できない問題があった（汎用性の問題）。
【０００７】
また、依頼回答メールと承認対象メールとの対応付けにはmail fromヘッダや対象メールのSubjectヘッダといった第三者にも知り得る情報を使用するため、第三者による成りすまし等による不正承認のリスクが存在した（安全性の問題）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１１８１７４号公報
【特許文献２】特開２０１０−１１４３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
通常の技術では、誤配信防止のための保留中メールの承認手続きには専用のWebシステムやクライアントなど対応する独自のユーザインタフェースが必要となり、開発の手間や運用コストの課題がある。
【００１０】
また、Webインタフェースの場合はログインを行う手間があったり、承認できる環境も限られてくるため承認手続きが滞留することも考えられる。
【００１１】
一方で、メールによる承認手続き方式も存在はしているが、成りすまし等による不正な承認が行われるリスクや、承認依頼メールが増えてくると承認が漏れたり、承認したかどうかの確認が困難になる問題があった。
【００１２】
本発明は、汎用性、安全性及び利便性が向上したメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明の第１の観点によれば、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、を備えることを特徴とするメール誤配信防止装置が提供される。
【００１４】
また、本発明によれば、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、を備えることを特徴とするメール誤配信防止装置が提供される。
【００１５】
また、本発明によれば、承認者に承認キーワードを含む承認依頼メールを送信し、前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法が提供される。
【００１６】
更に、本発明によれば、メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、前記コンピュータを、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、として機能させるためのメール誤配信防止プログラムが提供される。
【発明の効果】
【００１７】
本発明によれば、メール誤配信防止における汎用性、安全性及び利便性が向上する。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態１によるメール誤配信防止装置の構成及びメール誤配信防止装置の周辺の構成を示すブロック図である。
【図２】本発明の実施形態によるユーザ管理ディレクトリの構成を示す図である。
【図３】本発明の実施形態によるシステム情報設定ファイルの構成を示す図である。
【図４】本発明の実施形態において誤配信防止の対象となるメールの一例を示す図である。
【図５】本発明の実施形態による誤配信防止装置に含まれる承認依頼処理部の動作を説明するためのフローチャートである。
【図６】本発明の実施形態で用いられる承認キーワードの一例を示す図である。
【図７】本発明の実施形態による誤配信防止装置に含まれる送信メールデータベースの構成を示す図である。
【図８】本発明の実施形態で用いられる承認依頼メールの一例を示す図である。
【図９】本発明の実施形態で用いられる承認回答メールの一例を示す図である。
【図１０】本発明の実施形態による誤配信防止装置に含まれる承認処理部の動作を説明するためのフローチャートである。
【図１１】本発明の実施形態で用いられる結果通知メールの一例を示す図である。
【図１２】本発明の実施形態２によるメール誤配信防止装置の構成及びメール誤配信防止装置の周辺の構成を示すブロック図である。
【図１３】本発明の実施形態３で用いられるユーザ管理ディレクトリの構成を示す図である。
【図１４】本発明の実施形態３で用いられる送信メール管理データベースの構成を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明を実施するための形態について詳細に説明する。
【００２０】
本実施形態では、メールクライアントを特定せず全てのメールクライアントで同等の手続きを可能とし（汎用性の向上）、承認対象メールを一意に特定する暗号化されたキーワードを使用することや（安全性の向上）、誤配信防止装置からの各通知メールについて、クライアントが保留状態を容易に確認できるようなメールとすること（利便性の向上）で、上記の問題を克服できるものである。
【００２１】
本実施形態では、誤配信防止装置がメールを受信すると、メールの情報から暗号化された一意の承認キーワードを生成する。
【００２２】
そこで生成された承認キーワードを誤配信防止装置のメール管理データベースに格納し、承認キーワードを記述した承認依頼メールを承認者に対して送信する。
【００２３】
承認者は承認依頼メールを元に、承認用コマンドと承認キーワード及び禁止する場合には禁止理由を記述した依頼回答メールを作成し、承認依頼メールの送信元である誤配信防止装置に対して送信する。
【００２４】
依頼回答メールを受信した誤配信防止装置は通知された承認キーワードから保留していた送信メールを特定し、コマンドに従い当該メールの配信実施あるいは配信禁止の処理を行う。
【００２５】
本実施形態では承認判定時に依頼回答メールのToヘッダ、Fromヘッダ、及びメール本文の情報のみを使用するため全ての一般的なメールクライアントで同等の承認手続きが可能となる。
【００２６】
また、承認キーワードには承認者のみに通知される、承認対象のメールを一意に識別する暗号化された文字列を使用することで、第三者による不正な承認手続きを防ぐことを可能とする。
【００２７】
さらに、承認依頼メールや承認結果通知メールなど承認者への通知メールに対象メールを添付すること、通知メールのヘッダに対象メールや関連する通知メールに対応したIn-Reply-Toヘッダ及びReferencesヘッダを付与することで承認者のメールクライアントで関連するメールをスレッド表示可能とすること、承認依頼に対する禁止回答時に禁止理由を通知できるようにすることにより直感的に関連するメールや承認完了していないメールの抽出、保留中メールの状態を把握することを可能とする。
【００２８】
本実施形態では汎用のメールクライアントから配信承認手続きを行うことを可能とする。
【００２９】
これにより、HTTP等によるWebシステムへのアクセスを必要とせず、メールクライアントの特定もしないため特殊な環境は不要となり、携帯電話等からでも容易に承認処理を行うことができるようになる。
【００３０】
さらに本実施形態では、承認時に使用する承認対象メールを特定するキーワードに暗号化された一意のキーワードを使用することで、成りすまし等による不正な承認手続きを防ぐことが可能となる。
【００３１】
また、承認依頼メールに対象送信メールを添付したり、利用者側のメールクライアントで対象送信メールと承認依頼メールをスレッド表示可能とすることで、送信者自身や承認者による保留中メールの配信承認漏れや誤りを防ぐことが可能となる。
【００３２】
［実施形態１］
図１を参照すると、本発明の実施形態は、対象メールの発信者となるメールクライアント１と、誤配信防止装置２と、対象メールの受信者となるメールクライアント４を含む。
【００３３】
メールクライアント１及びメールクライアント４は、汎用のメールクライアントであり、Webメールや携帯電話端末のメーラを含む。
【００３４】
誤配信防止装置２は、承認依頼処理部２１と、承認処理部２２と、当該装置でユーザやメールの情報を保存するデータ領域２３を含む。
【００３５】
承認依頼処理部２１は、承認キーワード生成処理部２１１と、承認依頼送信処理部２１２を含む。
【００３６】
承認処理部２２は、承認結果判定処理部２２１と、メール配信処理部２２２と、メール情報削除処理部２２３を含む。
【００３７】
また、データ領域２３には、誤配信防止装置２を利用するユーザの情報が格納されたユーザ管理ディレクトリ２３１と、保留中のメールの送信情報を管理するメール管理データベース２３２と、誤配信防止装置２のシステム情報設定ファイル２３３が置かれる。
【００３８】
承認キーワード生成処理部２１１では、誤配信防止装置２のユーザ管理ディレクトリ２３１、送信メール管理データベース２３２、システム情報設定ファイル２３３及びOSの管理情報から取得されるメール発信者のユーザID、承認システムのバージョン情報、対象送信メール及び承認依頼メールのメッセージID、処理時刻、処理プログラム等の情報を暗号化することで、承認キーワードを作成する。
【００３９】
承認依頼送信処理部２１２は、承認キーワード生成処理部２１１で作成された承認キーワードと承認対象のメールの情報を送信メール管理データベース２３２に登録し、承認者に対して承認依頼メール１２１を送信する。
【００４０】
承認結果判定処理部２２１は、依頼回答メール１２２で通知された承認キーワードに対応する対象送信メールの情報を送信メール管理データベース２３２から取り出し、依頼回答メール１２２で承認キーワードと同時に通知される「承認」/「禁止」指示に従い、保留中メールの承認判定を行う。
【００４１】
メール配信処理部２２２は、依頼回答メール１２２で「承認」が通知された場合は承認結果判定処理部２２１で取り出した保留中メールを受信者４１に対して送信し、発信者/承認者に対して正常配信した旨の通知メール１２３を送信する。
【００４２】
一方、メール配信処理部２２２は、依頼回答メール１２２で「禁止」が通知された場合は受信者４１に対してメールの配信は行わず、発信者/承認者に対して配信禁止された旨の通知メール１２３を送信する。
【００４３】
メール配信処理部２２２が、メール送信を完了した後、メール情報削除処理部２２３にて、当該保留中メールの情報を送信メール管理データベース２３２から削除する。
【００４４】
誤配信防止の処理を始める前に、誤配信防止装置２のユーザ管理ディレクトリ２３１には、予め図２に示す利用者情報が、各利用者（各メール送信者及び各承認者）毎に定義されていることとする。
【００４５】
図２を参照すると、ユーザ管理ディレクトリ２３１には利用者毎に、ユーザID（Ｄ１）、メールアドレス（Ｄ２）、送信メール管理データベースの格納場所（Ｄ３）、承認者のメールアドレス（Ｄ４）、承認依頼通知に元メールの本体を添付するかどうかの設定（Ｄ５）、承認依頼通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ６）、承認結果通知に元メールの本体を添付するかどうかの設定（Ｄ７）、承認結果通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ８）、承認催促通知に元メールの本体を添付するかどうかの設定（Ｄ９）、承認催促通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ１０）、送信者自身による自己承認を必要とするかどうかの設定（Ｄ１１）、第三者による承認を必要とするかどうかの設定（Ｄ１２）、ユーザの代替（別名）メールアドレス（Ｄ１３）が設定される。
【００４６】
ここで、代替（別名）メールアドレス（Ｄ１３）としては、複数のメールアドレスを設定可能とする。
【００４７】
また、誤配信防止装置２のシステム情報設定ファイル２３３の内容を図３に示す。
【００４８】
システム情報設定ファイル２３３には、承認システムのバージョン、社内ドメインとして扱うドメインの定義、誤配信防止装置２のホスト名、ホストID、IPアドレス、ユーザ管理ディレクトリ２３１のパス、誤配信防止装置２のメールアドレスが設定される。システム情報設定ファイル２３３は、承認キーワード（後述の図６）の作成や誤配信防止装置２が受信したメールの振り分けや誤配信防止装置２が送信するメールの作成に利用される。
【００４９】
次に、誤配信防止の処理の詳細を説明する。
【００５０】
誤配信防止装置２が、発信者１１より誤配信防止の対象メールであるオリジナルメール１１１を受信すると、最初に承認依頼処理部２１が動作を開始する。
【００５１】
図４は、オリジナルメール１１１の例を示す。図４を参照すると、オリジナルメール１１１は、メールヘッダＪ１、メール本文Ｊ２、添付ファイルＪ３を含む。
【００５２】
メールヘッダＪ１において、Fromヘッダにオリジナルメール１１１の発信者１１のメールアドレス、Toヘッダには送信先である受信者４１のメールアドレス、Message-IDヘッダには発信者１１のメールクライアント１で付与されるメールを特定するIDが設定される。
【００５３】
メール本文Ｊ２には発信者１１が作成したメール本文が記述され、添付ファイルを付与した場合は添付ファイルＪ３に添付ファイルが含まれる。
【００５４】
次に、承認依頼処理部２１の動作の詳細について図５を参照して説明する。図５を参照すると、発信者１１が作成したメールを受信した誤配信防止装置２は、当該メールの送信先メールアドレスのドメイン部がシステム情報設定ファイル２３３で定義された社内ドメインと一致しないか否か（当該メールが誤配信防止の対象であるか否か）判定し（ステップＡ１）、一致しない場合は（当該メールが誤配信防止の対象である場合は）（ステップＡ１で「はい」）、社外宛のメールと判断して以下の処理を実施する。
【００５５】
オリジナルメール１１１が誤配信防止の対象と判定された場合は（ステップＡ１で「はい」）、オリジナルメール１１１の送信元である発信者１１のメールアドレスを元にユーザ管理ディレクトリ２３１で定義されているメール発信者１１のユーザID（Ｄ１）と、当該ユーザの送信メール管理データベース２３２の格納場所（Ｄ３）を特定し（ステップＡ２）、さらに、特定した発信者１１のユーザID（Ｄ１）及び承認システムのバージョン情報、オリジナルメール１１１のメッセージID、承認依頼メール１２１に指定するメッセージID、処理時刻、処理プロセスのプロセスID、誤配信防止装置２のIPアドレスから作成される文字列を暗号化して、承認キーワードを作成する（ステップＡ３）。
【００５６】
ここで使用する承認システムのバージョン情報や誤配信防止装置２のIPアドレスはシステム情報設定ファイル２３３から取得すればよく、オリジナルメール１１１のメッセージIDとしてはオリジナルメール１１１のメールヘッダＪ１に指定されるMessage-IDを使用すればよい。
【００５７】
また、承認依頼メール１２１に指定するメッセージIDは、処理日時や誤配信防止装置２のホスト名、ホストID、シーケンス番号、処理プロセスのプロセスID及びスレッドIDを使用して一意に作成される。
【００５８】
ここで使用する誤配信防止装置２のホスト名やホストIDとしてはシステム情報設定ファイル２３３に定義されている設定を使用すればよく、シーケンス番号は同時刻に複数件のメールを処理する際にそれぞれのメールを区別するための枝番号である。
【００５９】
ステップＡ３で作成する承認キーワードの内容を図６に示す。
【００６０】
図６を参照すると、承認キーワードＫ１は、オリジナルメール１１１の送信ユーザIDを暗号化した文字列Ｋ２と、区切り文字の＠、承認システムのバージョン情報やメッセージID等前記の情報を暗号化した文字列Ｋ３と、４桁のチェック用ハッシュＫ４を含む。
【００６１】
ここで使用する暗号化方式は、特定の暗号化方式に限定されず、例えば、ＤＥＳ(Data Encryption Standard)、３ＤＥＳ(Triple-DES)、ＡＥＳ(Advanced Encryption Standard)、ＩＤＥＡ(International Data Encryption Algorithm)、ＢＬＯＷＦＩＳＨ等既知の暗号化手法から選択できる。
【００６２】
次に、作成された図６に示す承認キーワードとオリジナルメール１１１の情報をステップＡ２で特定した送信メール管理データベース２３２のレコードに登録する（ステップＡ４）。
【００６３】
送信メール管理データベース２３２に登録する内容を、図７に示す。
【００６４】
送信メール管理データベース２３２には、承認キーワード（Ｅ１）やオリジナルメール１１１の処理時刻（Ｅ２）、オリジナルメール１１１の保存先（Ｅ３）、オリジナルメール１１１のメッセージID（Ｅ４）、承認依頼メールのメッセージID（Ｅ５）等が設定される。
【００６５】
その後、誤配信防止装置２は、承認依頼メール１２１のRFC822のReferencesヘッダ及びIn-Reply-Toヘッダにオリジナルメール１１１のMessage-IDを指定し、メール本文には保留対象メールの配信承認/禁止手順及び前記で作成した承認キーワード（図６参照）を記載し、ユーザ管理ディレクトリ２３１から取り出した当該ユーザに対する承認者メールアドレス（Ｄ４）宛に送信する（ステップＡ５）。
【００６６】
また、承認依頼メール１２１にはユーザ管理ディレクトリ２３１の設定により、元メールの添付有無（Ｄ５）、さらに元メールを添付する際に元メール自体の添付ファイルを付与するか（Ｄ６）を指定することができる。
【００６７】
元メール及び元メールへの添付ファイルのそれぞれが付与するよう指定されている場合は、ステップＡ５の承認依頼メール１２１送信時に、元メール及び元メールへの添付ファイルのそれぞれ承認依頼メール１２１に添付して送信することができる。
【００６８】
以上で承認依頼処理は完了となる。
【００６９】
図８に承認依頼メール１２１の例を示す。
【００７０】
承認依頼メール１２１はメールヘッダ（Ｌ１）、承認者への承認依頼と承認方法を通知するメール本文（Ｌ２）、添付ファイル（Ｌ３）を含む。
【００７１】
メールヘッダＬ１では、Fromヘッダとしてシステム情報設定ファイル２３３で設定された誤配信防止装置２のメールアドレス、Toヘッダとしてユーザ管理ディレクトリに設定されている承認者のメールアドレス、Message-IDヘッダとして承認依頼メールのメッセージID、Referencesヘッダ及びIn-Reply-Toヘッダとしてオリジナルメール１１１のMessage-IDが指定される。
【００７２】
元メールの添付が指定されている場合には、添付ファイル（Ｌ３）としてオリジナルメール及びオリジナルメールへの添付ファイルが添付される。
【００７３】
次に、承認依頼メール１２１を受信した発信者/承認者１２は、依頼回答メール１２２を作成し、承認依頼メール１２１の送信元である誤配信防止装置２のメールアドレスに対して送信する。
【００７４】
図９を参照すると、依頼回答メール１２２はメールヘッダ（Ｍ１）と承認あるいは禁止指示を記述したメール本文（Ｍ２）を含む。図９に示す例は、メール配信を禁止する場合のものである。
【００７５】
メールヘッダ（Ｍ１）のToヘッダには承認依頼メール１２１の送信先メールアドレスを設定する。
【００７６】
ここで設定する送信先メールアドレスはシステムにより決められたメールアドレスであり、承認、禁止に関わらず常に一定のものである。
【００７７】
依頼回答メール１２２ではメール本文（Ｍ２）の１行目は、承認／禁止コマンド及び承認キーワードを含む。１行目に含まれる承認／禁止コマンドは、対象メールの送信の承認を命令する「approve」又は禁止を命令する「disapprove」である。また図９に示す承認キーワードの一例は、図６に示すものと同一である。
【００７８】
また、メール本文（Ｍ２）の２行目に「Reason」を記述すれば、それ以降に記述されている文言を禁止理由として扱うことができる（Ｍ２２）。
【００７９】
ここで、「approve」、「disapprove」及び「Reason」の文字列は、それぞれ、認証、禁止、理由を表し、且つ、システムで予め定めた文字列であればよい。従って、「approve」、「disapprove」及び「Reason」の代わりに、それぞれ、例えば、「承認」、「禁止」、「理由」を用いてもよい。
【００８０】
承認／禁止コマンドや承認キーワードは全て承認依頼メール１２１で通知されるものである。
【００８１】
なお、依頼回答メール１２２の本文は、承認／禁止コマンド及び承認キーワードのみを含んでいればよい。また、必要な場合には、更に、禁止理由の内容のみを追加するだけでよい。従って、依頼回答メール１２２の本文は、承認依頼メール１２１の引用文等を含んでいる必要はない。
【００８２】
また、依頼回答メール１２２は、ReferencesヘッダやIn-Reply-Toヘッダも必要としないため、承認依頼メール１２１に対する返信メールである必要もない。
【００８３】
続いて、図１０を参照して承認処理部２２の動作を説明する。
【００８４】
図１０を参照すると、発信者/承認者１２が送信した依頼回答メール１２２を誤配信防止装置２が受信する。受信したメールの宛先がシステム情報設定ファイル２３３で定義された誤配信防止装置２のメールアドレスであれば、依頼回答メール１２２であると判定する（ステップＢ１で「はい」）。
【００８５】
受信したメールが依頼回答メールである場合は、依頼回答メール１２２の本文に記載されている承認キーワード（図６参照）を復号しユーザIDを取得する（ステップＢ２）。
【００８６】
ここで、取得したユーザIDをキーにして、ユーザ管理ディレクトリ２３１から承認者メールアドレスリスト（Ｄ４）を取得し、受信した依頼回答メール１２２の送信元である発信者/承認者１２のメールアドレスと一致するメールアドレスが承認者メールアドレスリスト（Ｄ４）に存在するかチェックを行う。一致するメールアドレスが存在した場合に次の処理に進む。
【００８７】
なお、依頼回答メール１２２の送信元が承認者であるか否かのチェック処理では、依頼回答メール１２２の送信元のメールアドレスが、例えば承認者の携帯電話のメールアドレスなど、事前にユーザ管理ディレクトリ２３１に登録された承認者の代替（別名）メールアドレスであっても、正しい承認者として判定するようにしてもよい。
【００８８】
次に、ステップＢ２で取得したユーザIDをキーにして、ユーザ管理ディレクトリ２３１から送信メール管理データベース２３２の格納場所（Ｄ３）を取得し（ステップＢ３）、承認キーワード（図６参照）を元に、対応するメールデータを送信メール管理データベース２３２から取り出す（ステップＢ４）。
【００８９】
承認キーワードが本文中に見つからない場合や、承認キーワードに対応するメールデータが送信メール管理データベース２３２に存在しない場合は、発信者/承認者１２に対して承認処理に失敗した旨のメールを通知し、以降の処理は実施しない。
【００９０】
依頼回答メール１２２の本文に値が「approve」である承認／禁止コマンドが含まれている場合は「承認」と判断し（ステップＢ５で「承認」）、保留していたメールをその宛先に対して送信する（ステップＢ６）。
【００９１】
その後、通知メール１２３のReferencesヘッダにオリジナルメール１１１のメッセージID(Message-ID)及び送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージID(Message-ID)を記述し、In-Reply-Toヘッダには送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、Message-IDヘッダには誤配信防止装置２で作成されたメッセージIDを記述し、メール本文には承認に応じた処理が完了しオリジナルメール１１１を配信した旨のメッセージを記述し、通知メール１２３を発信者/承認者１２に対して送信する（ステップＢ７）。
【００９２】
なお、通知メール１２３に記述するメッセージIDは、処理日時や誤配信防止装置２のホスト名、ホストID、シーケンス番号、処理プロセスのプロセスID及びスレッドIDを使用して一意に作成される。
【００９３】
ここで使用する誤配信防止装置２のホスト名やホストIDとしてはシステム情報設定ファイル２３３に定義されている設定を使用すればよく、シーケンス番号は同時刻に複数件のメールを処理する際にそれぞれのメールを区別するための枝番号である。
【００９４】
一方、依頼回答メール１２２の本文に値が「disapprove」である承認／禁止コマンドが含まれている場合は「禁止」と判断し（ステップＢ５で「禁止」）、保留していたメールは配信しない。通知メール１２３のReferencesヘッダにオリジナルメール１１１のメッセージID及び送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、In-Reply-Toヘッダには送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、Message-IDヘッダには誤配信防止装置２で作成されたメッセージIDを記述し、メール本文には保留していたメールの配信を中止した旨のメッセージを記述し、通知メール１２３を発信者/承認者１２に対して送信する（ステップＢ７）。
【００９５】
通知メール１２３に記述するメッセージIDとしては、承認／禁止コマンドが「approve」である場合と同様の方法により誤配信防止装置２で作成されたIDを使用する。
【００９６】
また、この時、メール本文には依頼回答メール１２２で通知された禁止理由（Ｍ２２）を記述できることとする。
【００９７】
なお、承認時及び禁止時の通知メール１２３には、ユーザ管理ディレクトリ２３１の設定により、元メールを添付したり、さらに元メールを添付する場合には、元メールへ添付ファイルを添付したりすることができる。
【００９８】
配信禁止時の通知メール１２３の例を図１１に示す。図１１を参照すると、配信禁止時の通知メール１２３には、メールヘッダＮ１と、配信が禁止されたこととその理由を通知するメール本文Ｎ２が含まれる。また、元メールの添付が指定されている場合には、元メールが添付ファイルＮ３として添付される。同様に、元メールへの添付ファイルの添付が指定されている場合には、元メールへの添付ファイルが添付ファイルＮ３として添付される。
【００９９】
最後に、送信メール管理データベース４から対象のメールデータのレコードを削除し、終了する（ステップＢ８）。
【０１００】
以上で承認処理部２２の動作は完了となる。
本実施形態は、特に以下の２点に特徴を有する。
・使用メールクライアントの汎用化装置
・保留メール承認時の詐称防止装置
◆使用メールクライアントの汎用化装置
本実施形態では以下の機能を実現することで、専用のメールクライアントを必要とせず、全ての一般的なメールクライアントで同等の機能を実現することができる。
・送信者が送信したメールが誤配信防止装置での保留対象かどうか判断するには、送信メールに設定されているRFC821で規定されている一般的なメールヘッダであるRCPT TOヘッダを使用する。
【０１０１】
また、前記ではRCPT TOヘッダ単独で判断することを説明したが、ユーザ管理ディレクトリに各ユーザ毎の誤配信防止の要否を指定することで、送信メールのRCPT TOヘッダとMAIL FROMヘッダから判断することも可能となる。
【０１０２】
つまり、同じ外部の宛先にメールを送信する場合でも、機密情報を送るAさんは誤配信防止の対象とし、機密情報を送らないBさんは誤配信防止の対象としないといった対応が可能となり、より柔軟性を持った機能実現が可能となる。
・保留中メールの特定に承認者が送信するメール本文中に記載される承認キーワードを使用することで、特別なクライアントシステムを必要とせず、安全に承認対象のメールを特定することができる。
・保留中メールを承認するか禁止するかの指示には、承認者が送信するメール本文中に記載される承認か禁止かを示す文字列を使用する。
・メールクライアント側で関連するメールをスレッド表示して参照するには、誤配信防止装置から通知するメールにもRFC822で規定されている一般的なメールヘッダであるReferencesヘッダとIn-Reply-Toヘッダを指定することで実現可能であるが、さらに、誤配信防止装置から通知するメールのSubjectヘッダの前部を対象送信メールのSubjectヘッダの内容と同じものとすることで、メールクライアントでSubject内容によるソートを行ったときに、関連するメールを全てまとめて確認することが可能となる。
【０１０３】
Subjectヘッダの内容でソートを行う際の、Subjectヘッダの設定例を以下に示す。
(例)
それぞれのメールのSubjectヘッダを以下とすることで、ソート表示した場合に関連するメールのみをまとめて参照することができる。
【０１０４】
対象送信メールのSubjectヘッダ
Subject : 来週の打ち合わせの件
誤配信防止装置が送信する承認依頼メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認依頼）
Subject : 来週の打ち合わせの件（2010年12月1日 12:34:56 承認依頼）
誤配信防止装置が送信する禁止結果の通知メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認結果 -禁止）
Subject : 来週の打ち合わせの件（2010年12月1日 13:12:34 承認結果 -禁止）
誤配信防止装置が送信する承認結果の通知メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認結果 - 承認）
Subject : 来週の打ち合わせの件（2010年12月2日 10:01:12 承認結果 - 承認）
◆保留メール承認時の詐称防止装置
承認者からの依頼回答メールを受信した誤配信防止装置では、以下の２段階の方法で承認者の正当性を確認することが可能となる。
【０１０５】
以下の方法で不正な承認者と判断された場合には、承認手続きを行わないことで成りすまし等による承認手続きの詐称防止を実現する。
・ユーザIDと、依頼回答メールに設定されているMAIL FROMヘッダの対応チェック
まず依頼回答メールに記述されている承認キーワードを復号化し、中に含まれるユーザIDを取り出す。次に、前記で取得されたユーザIDから対応するユーザ情報管理ディレクトリを決定する。承認手続きが送信者自身による自己承認の場合は、前記で決定されたユーザ情報管理ディレクトリに含まれるメールアドレス属性と依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダの内容を比較し、第三者による承認手続きの場合は、前記で決定されたユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダの内容を比較し、それぞれ比較結果が一致する場合には、次の承認キーワードと依頼回答メールに設定されているMAIL FROMヘッダの対応チェックを行う。一致しない場合には、配信を禁止する。
・承認キーワードと、依頼回答メールに設定されているMAIL FROMヘッダの対応チェック
前記と同様に、承認キーワードを復号化し、中に含まれるユーザIDを取り出す。次に、取り出されたユーザIDに対応するユーザ情報管理ディレクトリから、送信メール管理データベース格納場所を取得する。送信メール管理データベースから、依頼回答メールに記述されている承認キーワードに対応するレコードを取り出し、そこに登録されている承認者のメールアドレスを取り出す。ここで取り出された承認者のメールアドレスと、依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致するか比較することで承認者の正当性をチェックする。正当でなかったら配信を禁止する。
【０１０６】
なお、図７では承認者のメールアドレスのフィールドは省略しているが、図５を用いて説明した方法で承認依頼メールを作成する際に、承認者のメールアドレス（承認依頼メールのメールヘッダであるToヘッダ及びRCPT TOヘッダに設定するメールアドレス）を送信メール管理データベースに登録することで本手順を実現する。
【０１０７】
以上説明したように、本実施形態によれば、以下に記載するような効果を奏する。
【０１０８】
第１の効果は、承認及び禁止の手続きを普段利用している汎用のメールクライアントを使用して実施できることである（汎用性の向上）。
【０１０９】
その理由は、まず、承認及び禁止の手続きが全てメール送信により実現可能であることである。また、その理由は、承認手続きに承認／禁止コマンドを使用し、依頼回答メールにReferencesヘッダやIn-Reply-Toヘッダを使用しないことである。
【０１１０】
第２の効果は、承認手続きで対象のメールを一意に特定することができ、成りすましによる不正承認などセキュリティ上のリスクを低減することができることである（安全性の向上）。
【０１１１】
その理由は、承認及び禁止の手続きにメールIDを使用せず、ユーザIDやメールを一意に特定する情報を暗号化した承認キーワードをメール本文に記述して使用することである。
【０１１２】
第３の効果は、メール配信の禁止通知を受信したユーザが禁止された理由を速やかに認識できることである（利便性の向上）。
【０１１３】
その理由は、承認者が依頼回答メールで禁止理由を通知し、その禁止理由を元の発信者への結果通知メールで通知できることである。配信を禁止する理由には宛先アドレスの誤りや本文や添付ファイルに機密情報を含んでいるなど数多く考えられるが、発信者に禁止理由を通知することで発信者は速やかに問題点を認識することができ、発信者と承認者との不要なやり取りなどに費やされる手間や時間を削減することができる。
【０１１４】
第４の効果は、ユーザのメールクライアントで関連するメールをスレッド表示して参照することができ、まだ結果が返ってきていないメールや禁止されたメール、元メールの情報を容易に確認可能となることにある（利便性の向上）。
【０１１５】
その理由は、誤配信防止装置から送信する承認依頼メールや承認結果通知メールにReferencesヘッダ、In-Reply-Toヘッダを付与することにある。
【０１１６】
第５の効果は、各通知メールに元メール及び元メールへの添付ファイルを添付していると通知メールの容量が大きくなり過ぎることがあるが、その場合に、ユーザ単位で元メールへの添付ファイルを通知メールに添付しないようにしたり、元メールを通知メールに添付しないようにしたりすることで、よりユーザの環境に合わせた自由な利用が可能になることである（利便性の向上）。
【０１１７】
その理由は、誤配信防止装置から送信する承認依頼メールや依頼回答メールに承認対象の元メール自身や元メールへの添付ファイルを含めるか否かをユーザ毎に設定可能なことである。
【０１１８】
第６の効果は、承認者が承認依頼に対して回答する際に承認の場合、禁止の場合によってそれぞれ回答宛先を意識する必要がなく、宛先誤りによる意図しない承認や禁止を防止できることにある（安全性の向上）。
【０１１９】
その理由は、承認依頼通知に対する依頼回答メールの宛先としてはシステムで決められた唯一の固定メールアドレスを使用することである。
【０１２０】
［実施形態２］
本実施形態による誤配信防止装置は、承認者を発信者自身とすることで、メールを外部に送信する際の自己承認の手段として利用することが出来る。
【０１２１】
承認者を発信者自身とするか又は第三者とするかを示す情報をユーザ管理ディレクトリ２３１（図２参照）の自己承認実施要否（Ｄ１１）及び第三者承認実施要否（Ｄ１２）に登録する。例えば、自己承認で承認されたメールについて、再度第三者である承認者に承認依頼を行い、発信者自身及び第三者による承認が完了した時点で元の宛先に対してメール配信を行う２段階の承認手順を行うことができる。また、自己承認のみを行い第三者による承認は行わないといった運用も採用することができる。
【０１２２】
上述した発信者自信及び第三者による２段階の承認手順の流れを、図１２に示す。
【０１２３】
［実施形態３］
また、実施形態１では誤配信防止の承認者を一名のみとしていたが、図１３の承認者メールアドレスＦ１に示すように、複数の承認者のメールアドレスを指定することができる。
【０１２４】
複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる。
【０１２５】
論理和条件方法を使用することによる効果は、承認者を複数指定することにより、或る承認者が不在でも別の承認者によって承認手続きを進めることができるようになることにある。また、論理積条件方法や多数決方法を使用することによる効果は、稟議目的のメールや予算書等重要要件について複数名の承認判定を必要とすることで機密情報流出のリスクを低減できることにある。
【０１２６】
各利用者毎に論理和条件方法を使用するか、論理積条件方法を使用するか、多数決方法を使用するかを指定するための設定情報をユーザ管理ディレクトリ２３１に保持することができる。論理積条件方法の場合は、一部の承認者から依頼回答メールがあった時点で直ぐにメールの配信を承認するのか禁止するのかを決定するのではなく、全ての承認者からの依頼回答メールが揃うまで各承認者からの結果を送信メール管理データベース２３２に保存し、全ての承認者からの依頼回答メールが揃ってから、承認あるいは禁止の判定を行うこととする。多数決方法の場合は、一部の承認者から依頼回答メールがあった時点で直ぐにメールの配信を承認するのか禁止するのかを決定するのではなく、多数決に必要な数の承認者からの依頼回答メールが揃うまで各承認者からの結果を送信メール管理データベース２３２に保存し、多数決に必要な数の承認者からの依頼回答メールが揃ってから、承認あるいは禁止の判定を行うこととする。
【０１２７】
具体的には、各利用者毎に論理和条件方法、論理積条件方法、多数決方法のうちのどれを使用するかに関する設定情報を、図１３の第三者承認方法Ｆ２に設定すればよく、各承認者からの結果は図１４の承認者メールアドレスの回答Ｇ２に保存すればよい。
【０１２８】
また、図１４の承認者数Ｇ１には、送信メール管理データベース２３２のレコード作成時に、図１３の承認者メールアドレスＦ１に設定されている承認者メールアドレスの数を設定する。
【０１２９】
承認者メールアドレスの回答Ｇ２には、承認者毎に承認か禁止かを表す情報（フラグなど）を保存することとし、ここに保存された情報と承認者数Ｇ１に基づいて、論理和方法、論理積方法又は多数決方法に従った許諾又は禁止の判定を行う。
【０１３０】
つまり、論理積条件方法の場合は、承認者メールアドレスＧ２の承認か禁止を表す情報が全て承認を示せば対象のメールの配信は承認されたと判定し、多数決方法の場合は、承認を示している情報に対応する承認者メールアドレスＧ２の数が過半数であれば承認されたと判定する。
【０１３１】
なお、承認者として複数名を指定した場合は承認依頼メール１２１と通知メール１２３の宛先には指定されている全ての承認者のメールアドレスを含むことで、全承認者が共通して対象のメールの承認状況を確認できるものとする。
【０１３２】
誤配信防止装置の各部は、ハードウェアによって構成することもできるが、その一部又は全部をソフトウェアによって構成することもできる。ここで、ソフトウェアによって構成するとは、コンピュータをその部分として機能させるためのプログラムをコンピュータが読み込んで実行することにより構成することを意味する。
【０１３３】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１３４】
（付記１）
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
を備えることを特徴とするメール誤配信防止装置。
【０１３５】
（付記２）
付記１に記載のメール誤配信防止装置であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段をさらに備えるメール誤配信防止装置。
【０１３６】
（付記３）
付記１又は２に記載のメール誤配信防止装置であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３７】
（付記４）
付記１乃至３の何れか１に記載のメール誤配信防止装置であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３８】
（付記５）
付記１乃至４の何れか１に記載のメール誤配信防止装置であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３９】
（付記６）
付記１乃至５の何れか１に記載のメール誤配信防止装置であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１４０】
（付記７）
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
を備えることを特徴とするメール誤配信防止装置。
【０１４１】
（付記８）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認するメール誤配信防止方法。
【０１４２】
（付記９）
付記８に記載のメール誤配信防止方法であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４３】
（付記１０）
付記８又は９に記載のメール誤配信防止方法であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４４】
（付記１１）
付記８乃至１０の何れか１に記載のメール誤配信防止方法であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４５】
（付記１２）
付記８乃至１１の何れか１に記載のメール誤配信防止方法であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４６】
（付記１３）
付記８乃至１２の何れか１に記載のメール誤配信防止方法であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、対象となっているメールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４７】
（付記１４）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４８】
（付記１５）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４９】
（付記１６）
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
として機能させるためのメール誤配信防止プログラム。
【０１５０】
（付記１７）
付記１６に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワード及び禁止を表す所定のデータが含まれている場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５１】
（付記１８）
付記１６又は１７に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５２】
（付記１９）
付記１６乃至１８の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５３】
（付記２０）
付記１６乃至１９の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５４】
（付記２１）
付記１６乃至２０の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５５】
（付記２２）
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
として機能させるためのメール誤配信防止プログラム。
【産業上の利用可能性】
【０１５６】
本発明は、メールの誤配信を問題とする全ての分野で利用可能である。
【０１５７】
企業等の保持するメールサーバに本発明の技術を組み込むことで、利用者端末には影響を与えず誤配信防止の仕組みを適用させることが可能となる。
【符号の説明】
【０１５８】
１ メールクライアント
２ 誤配信防止装置
４ メールクライアント
２１ 承認依頼処理部
２２ 承認処理部
２３ データ領域
１１１オリジナルメール（誤配信防止対象メール）
１２１ 承認依頼メール
１２２ 依頼回答メール
１２３ 通知メール
【技術分野】
【０００１】
本発明は、機密情報等を含む等の理由により、外部に送信されてはならないメールが誤って外部に送信されることを防止するためのメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラムに関する。
【背景技術】
【０００２】
通常、電子メールの誤配信を防止するために、一時保留した送信メールの承認を送信者自身や第三者により行ってから外部に配信する仕組みは存在していたが、送信を承認するためには専用のWebシステムやクライアントを使用して承認手続きを行う方法が主流である。
【０００３】
通常は、特開２００９−１１８１７４号公報「情報処理装置、承認方法、およびプログラム」（特許文献１）のように、誤配信防止のための第三者承認手続きをユーザのメールクライアントから実施する方式は知られていたが、クライアントから送信するメールにはReferencesヘッダやIn-Reply-Toヘッダが付与されている必要があり、さらに承認回答にはメールクライアントの「全員に返信」機能を使用するため、前記ヘッダが付与されないメールクライアントや、「全員に返信」機能が備わっていないメールクライアントでは対応できない問題があった（汎用性の問題）。
【０００４】
また、承認と禁止の判断には依頼回答メールの宛先メールアドレスを使用して区別するため、承認者が承認と禁止との間の誤りを起こしやすい問題や、Referenceヘッダには複数のメールＩＤが指定されていることもあり、依頼回答メールは必ずしも承認対象のメールを一意に特定するものではないという問題があった（安全性の問題）。
【０００５】
さらに、ある承認対象メールに対する承認依頼メールと承認結果通知メールの関連付けができないため、承認依頼が多数になってくると承認漏れや確認のための手間が必要となる問題があった（利便性の問題）。
【０００６】
また、特開２０１０−１１４３５号公報「電子メール保留システム」（特許文献２）も知られているが、この技術では専用のクライアントソフトを使用するため、汎用のメールクライアントソフトでは対応できない問題があった（汎用性の問題）。
【０００７】
また、依頼回答メールと承認対象メールとの対応付けにはmail fromヘッダや対象メールのSubjectヘッダといった第三者にも知り得る情報を使用するため、第三者による成りすまし等による不正承認のリスクが存在した（安全性の問題）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１１８１７４号公報
【特許文献２】特開２０１０−１１４３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
通常の技術では、誤配信防止のための保留中メールの承認手続きには専用のWebシステムやクライアントなど対応する独自のユーザインタフェースが必要となり、開発の手間や運用コストの課題がある。
【００１０】
また、Webインタフェースの場合はログインを行う手間があったり、承認できる環境も限られてくるため承認手続きが滞留することも考えられる。
【００１１】
一方で、メールによる承認手続き方式も存在はしているが、成りすまし等による不正な承認が行われるリスクや、承認依頼メールが増えてくると承認が漏れたり、承認したかどうかの確認が困難になる問題があった。
【００１２】
本発明は、汎用性、安全性及び利便性が向上したメール誤配信防止装置、メール誤配信防止方法及びメール誤配信防止プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明の第１の観点によれば、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、を備えることを特徴とするメール誤配信防止装置が提供される。
【００１４】
また、本発明によれば、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、を備えることを特徴とするメール誤配信防止装置が提供される。
【００１５】
また、本発明によれば、承認者に承認キーワードを含む承認依頼メールを送信し、前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法が提供される。
【００１６】
更に、本発明によれば、メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、前記コンピュータを、承認者に承認キーワードを含む承認依頼メールを送信する手段と、前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、として機能させるためのメール誤配信防止プログラムが提供される。
【発明の効果】
【００１７】
本発明によれば、メール誤配信防止における汎用性、安全性及び利便性が向上する。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態１によるメール誤配信防止装置の構成及びメール誤配信防止装置の周辺の構成を示すブロック図である。
【図２】本発明の実施形態によるユーザ管理ディレクトリの構成を示す図である。
【図３】本発明の実施形態によるシステム情報設定ファイルの構成を示す図である。
【図４】本発明の実施形態において誤配信防止の対象となるメールの一例を示す図である。
【図５】本発明の実施形態による誤配信防止装置に含まれる承認依頼処理部の動作を説明するためのフローチャートである。
【図６】本発明の実施形態で用いられる承認キーワードの一例を示す図である。
【図７】本発明の実施形態による誤配信防止装置に含まれる送信メールデータベースの構成を示す図である。
【図８】本発明の実施形態で用いられる承認依頼メールの一例を示す図である。
【図９】本発明の実施形態で用いられる承認回答メールの一例を示す図である。
【図１０】本発明の実施形態による誤配信防止装置に含まれる承認処理部の動作を説明するためのフローチャートである。
【図１１】本発明の実施形態で用いられる結果通知メールの一例を示す図である。
【図１２】本発明の実施形態２によるメール誤配信防止装置の構成及びメール誤配信防止装置の周辺の構成を示すブロック図である。
【図１３】本発明の実施形態３で用いられるユーザ管理ディレクトリの構成を示す図である。
【図１４】本発明の実施形態３で用いられる送信メール管理データベースの構成を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明を実施するための形態について詳細に説明する。
【００２０】
本実施形態では、メールクライアントを特定せず全てのメールクライアントで同等の手続きを可能とし（汎用性の向上）、承認対象メールを一意に特定する暗号化されたキーワードを使用することや（安全性の向上）、誤配信防止装置からの各通知メールについて、クライアントが保留状態を容易に確認できるようなメールとすること（利便性の向上）で、上記の問題を克服できるものである。
【００２１】
本実施形態では、誤配信防止装置がメールを受信すると、メールの情報から暗号化された一意の承認キーワードを生成する。
【００２２】
そこで生成された承認キーワードを誤配信防止装置のメール管理データベースに格納し、承認キーワードを記述した承認依頼メールを承認者に対して送信する。
【００２３】
承認者は承認依頼メールを元に、承認用コマンドと承認キーワード及び禁止する場合には禁止理由を記述した依頼回答メールを作成し、承認依頼メールの送信元である誤配信防止装置に対して送信する。
【００２４】
依頼回答メールを受信した誤配信防止装置は通知された承認キーワードから保留していた送信メールを特定し、コマンドに従い当該メールの配信実施あるいは配信禁止の処理を行う。
【００２５】
本実施形態では承認判定時に依頼回答メールのToヘッダ、Fromヘッダ、及びメール本文の情報のみを使用するため全ての一般的なメールクライアントで同等の承認手続きが可能となる。
【００２６】
また、承認キーワードには承認者のみに通知される、承認対象のメールを一意に識別する暗号化された文字列を使用することで、第三者による不正な承認手続きを防ぐことを可能とする。
【００２７】
さらに、承認依頼メールや承認結果通知メールなど承認者への通知メールに対象メールを添付すること、通知メールのヘッダに対象メールや関連する通知メールに対応したIn-Reply-Toヘッダ及びReferencesヘッダを付与することで承認者のメールクライアントで関連するメールをスレッド表示可能とすること、承認依頼に対する禁止回答時に禁止理由を通知できるようにすることにより直感的に関連するメールや承認完了していないメールの抽出、保留中メールの状態を把握することを可能とする。
【００２８】
本実施形態では汎用のメールクライアントから配信承認手続きを行うことを可能とする。
【００２９】
これにより、HTTP等によるWebシステムへのアクセスを必要とせず、メールクライアントの特定もしないため特殊な環境は不要となり、携帯電話等からでも容易に承認処理を行うことができるようになる。
【００３０】
さらに本実施形態では、承認時に使用する承認対象メールを特定するキーワードに暗号化された一意のキーワードを使用することで、成りすまし等による不正な承認手続きを防ぐことが可能となる。
【００３１】
また、承認依頼メールに対象送信メールを添付したり、利用者側のメールクライアントで対象送信メールと承認依頼メールをスレッド表示可能とすることで、送信者自身や承認者による保留中メールの配信承認漏れや誤りを防ぐことが可能となる。
【００３２】
［実施形態１］
図１を参照すると、本発明の実施形態は、対象メールの発信者となるメールクライアント１と、誤配信防止装置２と、対象メールの受信者となるメールクライアント４を含む。
【００３３】
メールクライアント１及びメールクライアント４は、汎用のメールクライアントであり、Webメールや携帯電話端末のメーラを含む。
【００３４】
誤配信防止装置２は、承認依頼処理部２１と、承認処理部２２と、当該装置でユーザやメールの情報を保存するデータ領域２３を含む。
【００３５】
承認依頼処理部２１は、承認キーワード生成処理部２１１と、承認依頼送信処理部２１２を含む。
【００３６】
承認処理部２２は、承認結果判定処理部２２１と、メール配信処理部２２２と、メール情報削除処理部２２３を含む。
【００３７】
また、データ領域２３には、誤配信防止装置２を利用するユーザの情報が格納されたユーザ管理ディレクトリ２３１と、保留中のメールの送信情報を管理するメール管理データベース２３２と、誤配信防止装置２のシステム情報設定ファイル２３３が置かれる。
【００３８】
承認キーワード生成処理部２１１では、誤配信防止装置２のユーザ管理ディレクトリ２３１、送信メール管理データベース２３２、システム情報設定ファイル２３３及びOSの管理情報から取得されるメール発信者のユーザID、承認システムのバージョン情報、対象送信メール及び承認依頼メールのメッセージID、処理時刻、処理プログラム等の情報を暗号化することで、承認キーワードを作成する。
【００３９】
承認依頼送信処理部２１２は、承認キーワード生成処理部２１１で作成された承認キーワードと承認対象のメールの情報を送信メール管理データベース２３２に登録し、承認者に対して承認依頼メール１２１を送信する。
【００４０】
承認結果判定処理部２２１は、依頼回答メール１２２で通知された承認キーワードに対応する対象送信メールの情報を送信メール管理データベース２３２から取り出し、依頼回答メール１２２で承認キーワードと同時に通知される「承認」/「禁止」指示に従い、保留中メールの承認判定を行う。
【００４１】
メール配信処理部２２２は、依頼回答メール１２２で「承認」が通知された場合は承認結果判定処理部２２１で取り出した保留中メールを受信者４１に対して送信し、発信者/承認者に対して正常配信した旨の通知メール１２３を送信する。
【００４２】
一方、メール配信処理部２２２は、依頼回答メール１２２で「禁止」が通知された場合は受信者４１に対してメールの配信は行わず、発信者/承認者に対して配信禁止された旨の通知メール１２３を送信する。
【００４３】
メール配信処理部２２２が、メール送信を完了した後、メール情報削除処理部２２３にて、当該保留中メールの情報を送信メール管理データベース２３２から削除する。
【００４４】
誤配信防止の処理を始める前に、誤配信防止装置２のユーザ管理ディレクトリ２３１には、予め図２に示す利用者情報が、各利用者（各メール送信者及び各承認者）毎に定義されていることとする。
【００４５】
図２を参照すると、ユーザ管理ディレクトリ２３１には利用者毎に、ユーザID（Ｄ１）、メールアドレス（Ｄ２）、送信メール管理データベースの格納場所（Ｄ３）、承認者のメールアドレス（Ｄ４）、承認依頼通知に元メールの本体を添付するかどうかの設定（Ｄ５）、承認依頼通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ６）、承認結果通知に元メールの本体を添付するかどうかの設定（Ｄ７）、承認結果通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ８）、承認催促通知に元メールの本体を添付するかどうかの設定（Ｄ９）、承認催促通知に元メールを添付時に、元メール自身の添付ファイルまで付与するかどうかの設定（Ｄ１０）、送信者自身による自己承認を必要とするかどうかの設定（Ｄ１１）、第三者による承認を必要とするかどうかの設定（Ｄ１２）、ユーザの代替（別名）メールアドレス（Ｄ１３）が設定される。
【００４６】
ここで、代替（別名）メールアドレス（Ｄ１３）としては、複数のメールアドレスを設定可能とする。
【００４７】
また、誤配信防止装置２のシステム情報設定ファイル２３３の内容を図３に示す。
【００４８】
システム情報設定ファイル２３３には、承認システムのバージョン、社内ドメインとして扱うドメインの定義、誤配信防止装置２のホスト名、ホストID、IPアドレス、ユーザ管理ディレクトリ２３１のパス、誤配信防止装置２のメールアドレスが設定される。システム情報設定ファイル２３３は、承認キーワード（後述の図６）の作成や誤配信防止装置２が受信したメールの振り分けや誤配信防止装置２が送信するメールの作成に利用される。
【００４９】
次に、誤配信防止の処理の詳細を説明する。
【００５０】
誤配信防止装置２が、発信者１１より誤配信防止の対象メールであるオリジナルメール１１１を受信すると、最初に承認依頼処理部２１が動作を開始する。
【００５１】
図４は、オリジナルメール１１１の例を示す。図４を参照すると、オリジナルメール１１１は、メールヘッダＪ１、メール本文Ｊ２、添付ファイルＪ３を含む。
【００５２】
メールヘッダＪ１において、Fromヘッダにオリジナルメール１１１の発信者１１のメールアドレス、Toヘッダには送信先である受信者４１のメールアドレス、Message-IDヘッダには発信者１１のメールクライアント１で付与されるメールを特定するIDが設定される。
【００５３】
メール本文Ｊ２には発信者１１が作成したメール本文が記述され、添付ファイルを付与した場合は添付ファイルＪ３に添付ファイルが含まれる。
【００５４】
次に、承認依頼処理部２１の動作の詳細について図５を参照して説明する。図５を参照すると、発信者１１が作成したメールを受信した誤配信防止装置２は、当該メールの送信先メールアドレスのドメイン部がシステム情報設定ファイル２３３で定義された社内ドメインと一致しないか否か（当該メールが誤配信防止の対象であるか否か）判定し（ステップＡ１）、一致しない場合は（当該メールが誤配信防止の対象である場合は）（ステップＡ１で「はい」）、社外宛のメールと判断して以下の処理を実施する。
【００５５】
オリジナルメール１１１が誤配信防止の対象と判定された場合は（ステップＡ１で「はい」）、オリジナルメール１１１の送信元である発信者１１のメールアドレスを元にユーザ管理ディレクトリ２３１で定義されているメール発信者１１のユーザID（Ｄ１）と、当該ユーザの送信メール管理データベース２３２の格納場所（Ｄ３）を特定し（ステップＡ２）、さらに、特定した発信者１１のユーザID（Ｄ１）及び承認システムのバージョン情報、オリジナルメール１１１のメッセージID、承認依頼メール１２１に指定するメッセージID、処理時刻、処理プロセスのプロセスID、誤配信防止装置２のIPアドレスから作成される文字列を暗号化して、承認キーワードを作成する（ステップＡ３）。
【００５６】
ここで使用する承認システムのバージョン情報や誤配信防止装置２のIPアドレスはシステム情報設定ファイル２３３から取得すればよく、オリジナルメール１１１のメッセージIDとしてはオリジナルメール１１１のメールヘッダＪ１に指定されるMessage-IDを使用すればよい。
【００５７】
また、承認依頼メール１２１に指定するメッセージIDは、処理日時や誤配信防止装置２のホスト名、ホストID、シーケンス番号、処理プロセスのプロセスID及びスレッドIDを使用して一意に作成される。
【００５８】
ここで使用する誤配信防止装置２のホスト名やホストIDとしてはシステム情報設定ファイル２３３に定義されている設定を使用すればよく、シーケンス番号は同時刻に複数件のメールを処理する際にそれぞれのメールを区別するための枝番号である。
【００５９】
ステップＡ３で作成する承認キーワードの内容を図６に示す。
【００６０】
図６を参照すると、承認キーワードＫ１は、オリジナルメール１１１の送信ユーザIDを暗号化した文字列Ｋ２と、区切り文字の＠、承認システムのバージョン情報やメッセージID等前記の情報を暗号化した文字列Ｋ３と、４桁のチェック用ハッシュＫ４を含む。
【００６１】
ここで使用する暗号化方式は、特定の暗号化方式に限定されず、例えば、ＤＥＳ(Data Encryption Standard)、３ＤＥＳ(Triple-DES)、ＡＥＳ(Advanced Encryption Standard)、ＩＤＥＡ(International Data Encryption Algorithm)、ＢＬＯＷＦＩＳＨ等既知の暗号化手法から選択できる。
【００６２】
次に、作成された図６に示す承認キーワードとオリジナルメール１１１の情報をステップＡ２で特定した送信メール管理データベース２３２のレコードに登録する（ステップＡ４）。
【００６３】
送信メール管理データベース２３２に登録する内容を、図７に示す。
【００６４】
送信メール管理データベース２３２には、承認キーワード（Ｅ１）やオリジナルメール１１１の処理時刻（Ｅ２）、オリジナルメール１１１の保存先（Ｅ３）、オリジナルメール１１１のメッセージID（Ｅ４）、承認依頼メールのメッセージID（Ｅ５）等が設定される。
【００６５】
その後、誤配信防止装置２は、承認依頼メール１２１のRFC822のReferencesヘッダ及びIn-Reply-Toヘッダにオリジナルメール１１１のMessage-IDを指定し、メール本文には保留対象メールの配信承認/禁止手順及び前記で作成した承認キーワード（図６参照）を記載し、ユーザ管理ディレクトリ２３１から取り出した当該ユーザに対する承認者メールアドレス（Ｄ４）宛に送信する（ステップＡ５）。
【００６６】
また、承認依頼メール１２１にはユーザ管理ディレクトリ２３１の設定により、元メールの添付有無（Ｄ５）、さらに元メールを添付する際に元メール自体の添付ファイルを付与するか（Ｄ６）を指定することができる。
【００６７】
元メール及び元メールへの添付ファイルのそれぞれが付与するよう指定されている場合は、ステップＡ５の承認依頼メール１２１送信時に、元メール及び元メールへの添付ファイルのそれぞれ承認依頼メール１２１に添付して送信することができる。
【００６８】
以上で承認依頼処理は完了となる。
【００６９】
図８に承認依頼メール１２１の例を示す。
【００７０】
承認依頼メール１２１はメールヘッダ（Ｌ１）、承認者への承認依頼と承認方法を通知するメール本文（Ｌ２）、添付ファイル（Ｌ３）を含む。
【００７１】
メールヘッダＬ１では、Fromヘッダとしてシステム情報設定ファイル２３３で設定された誤配信防止装置２のメールアドレス、Toヘッダとしてユーザ管理ディレクトリに設定されている承認者のメールアドレス、Message-IDヘッダとして承認依頼メールのメッセージID、Referencesヘッダ及びIn-Reply-Toヘッダとしてオリジナルメール１１１のMessage-IDが指定される。
【００７２】
元メールの添付が指定されている場合には、添付ファイル（Ｌ３）としてオリジナルメール及びオリジナルメールへの添付ファイルが添付される。
【００７３】
次に、承認依頼メール１２１を受信した発信者/承認者１２は、依頼回答メール１２２を作成し、承認依頼メール１２１の送信元である誤配信防止装置２のメールアドレスに対して送信する。
【００７４】
図９を参照すると、依頼回答メール１２２はメールヘッダ（Ｍ１）と承認あるいは禁止指示を記述したメール本文（Ｍ２）を含む。図９に示す例は、メール配信を禁止する場合のものである。
【００７５】
メールヘッダ（Ｍ１）のToヘッダには承認依頼メール１２１の送信先メールアドレスを設定する。
【００７６】
ここで設定する送信先メールアドレスはシステムにより決められたメールアドレスであり、承認、禁止に関わらず常に一定のものである。
【００７７】
依頼回答メール１２２ではメール本文（Ｍ２）の１行目は、承認／禁止コマンド及び承認キーワードを含む。１行目に含まれる承認／禁止コマンドは、対象メールの送信の承認を命令する「approve」又は禁止を命令する「disapprove」である。また図９に示す承認キーワードの一例は、図６に示すものと同一である。
【００７８】
また、メール本文（Ｍ２）の２行目に「Reason」を記述すれば、それ以降に記述されている文言を禁止理由として扱うことができる（Ｍ２２）。
【００７９】
ここで、「approve」、「disapprove」及び「Reason」の文字列は、それぞれ、認証、禁止、理由を表し、且つ、システムで予め定めた文字列であればよい。従って、「approve」、「disapprove」及び「Reason」の代わりに、それぞれ、例えば、「承認」、「禁止」、「理由」を用いてもよい。
【００８０】
承認／禁止コマンドや承認キーワードは全て承認依頼メール１２１で通知されるものである。
【００８１】
なお、依頼回答メール１２２の本文は、承認／禁止コマンド及び承認キーワードのみを含んでいればよい。また、必要な場合には、更に、禁止理由の内容のみを追加するだけでよい。従って、依頼回答メール１２２の本文は、承認依頼メール１２１の引用文等を含んでいる必要はない。
【００８２】
また、依頼回答メール１２２は、ReferencesヘッダやIn-Reply-Toヘッダも必要としないため、承認依頼メール１２１に対する返信メールである必要もない。
【００８３】
続いて、図１０を参照して承認処理部２２の動作を説明する。
【００８４】
図１０を参照すると、発信者/承認者１２が送信した依頼回答メール１２２を誤配信防止装置２が受信する。受信したメールの宛先がシステム情報設定ファイル２３３で定義された誤配信防止装置２のメールアドレスであれば、依頼回答メール１２２であると判定する（ステップＢ１で「はい」）。
【００８５】
受信したメールが依頼回答メールである場合は、依頼回答メール１２２の本文に記載されている承認キーワード（図６参照）を復号しユーザIDを取得する（ステップＢ２）。
【００８６】
ここで、取得したユーザIDをキーにして、ユーザ管理ディレクトリ２３１から承認者メールアドレスリスト（Ｄ４）を取得し、受信した依頼回答メール１２２の送信元である発信者/承認者１２のメールアドレスと一致するメールアドレスが承認者メールアドレスリスト（Ｄ４）に存在するかチェックを行う。一致するメールアドレスが存在した場合に次の処理に進む。
【００８７】
なお、依頼回答メール１２２の送信元が承認者であるか否かのチェック処理では、依頼回答メール１２２の送信元のメールアドレスが、例えば承認者の携帯電話のメールアドレスなど、事前にユーザ管理ディレクトリ２３１に登録された承認者の代替（別名）メールアドレスであっても、正しい承認者として判定するようにしてもよい。
【００８８】
次に、ステップＢ２で取得したユーザIDをキーにして、ユーザ管理ディレクトリ２３１から送信メール管理データベース２３２の格納場所（Ｄ３）を取得し（ステップＢ３）、承認キーワード（図６参照）を元に、対応するメールデータを送信メール管理データベース２３２から取り出す（ステップＢ４）。
【００８９】
承認キーワードが本文中に見つからない場合や、承認キーワードに対応するメールデータが送信メール管理データベース２３２に存在しない場合は、発信者/承認者１２に対して承認処理に失敗した旨のメールを通知し、以降の処理は実施しない。
【００９０】
依頼回答メール１２２の本文に値が「approve」である承認／禁止コマンドが含まれている場合は「承認」と判断し（ステップＢ５で「承認」）、保留していたメールをその宛先に対して送信する（ステップＢ６）。
【００９１】
その後、通知メール１２３のReferencesヘッダにオリジナルメール１１１のメッセージID(Message-ID)及び送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージID(Message-ID)を記述し、In-Reply-Toヘッダには送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、Message-IDヘッダには誤配信防止装置２で作成されたメッセージIDを記述し、メール本文には承認に応じた処理が完了しオリジナルメール１１１を配信した旨のメッセージを記述し、通知メール１２３を発信者/承認者１２に対して送信する（ステップＢ７）。
【００９２】
なお、通知メール１２３に記述するメッセージIDは、処理日時や誤配信防止装置２のホスト名、ホストID、シーケンス番号、処理プロセスのプロセスID及びスレッドIDを使用して一意に作成される。
【００９３】
ここで使用する誤配信防止装置２のホスト名やホストIDとしてはシステム情報設定ファイル２３３に定義されている設定を使用すればよく、シーケンス番号は同時刻に複数件のメールを処理する際にそれぞれのメールを区別するための枝番号である。
【００９４】
一方、依頼回答メール１２２の本文に値が「disapprove」である承認／禁止コマンドが含まれている場合は「禁止」と判断し（ステップＢ５で「禁止」）、保留していたメールは配信しない。通知メール１２３のReferencesヘッダにオリジナルメール１１１のメッセージID及び送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、In-Reply-Toヘッダには送信メール管理データベース２３２から取り出された承認依頼メール１２１のメッセージIDを記述し、Message-IDヘッダには誤配信防止装置２で作成されたメッセージIDを記述し、メール本文には保留していたメールの配信を中止した旨のメッセージを記述し、通知メール１２３を発信者/承認者１２に対して送信する（ステップＢ７）。
【００９５】
通知メール１２３に記述するメッセージIDとしては、承認／禁止コマンドが「approve」である場合と同様の方法により誤配信防止装置２で作成されたIDを使用する。
【００９６】
また、この時、メール本文には依頼回答メール１２２で通知された禁止理由（Ｍ２２）を記述できることとする。
【００９７】
なお、承認時及び禁止時の通知メール１２３には、ユーザ管理ディレクトリ２３１の設定により、元メールを添付したり、さらに元メールを添付する場合には、元メールへ添付ファイルを添付したりすることができる。
【００９８】
配信禁止時の通知メール１２３の例を図１１に示す。図１１を参照すると、配信禁止時の通知メール１２３には、メールヘッダＮ１と、配信が禁止されたこととその理由を通知するメール本文Ｎ２が含まれる。また、元メールの添付が指定されている場合には、元メールが添付ファイルＮ３として添付される。同様に、元メールへの添付ファイルの添付が指定されている場合には、元メールへの添付ファイルが添付ファイルＮ３として添付される。
【００９９】
最後に、送信メール管理データベース４から対象のメールデータのレコードを削除し、終了する（ステップＢ８）。
【０１００】
以上で承認処理部２２の動作は完了となる。
本実施形態は、特に以下の２点に特徴を有する。
・使用メールクライアントの汎用化装置
・保留メール承認時の詐称防止装置
◆使用メールクライアントの汎用化装置
本実施形態では以下の機能を実現することで、専用のメールクライアントを必要とせず、全ての一般的なメールクライアントで同等の機能を実現することができる。
・送信者が送信したメールが誤配信防止装置での保留対象かどうか判断するには、送信メールに設定されているRFC821で規定されている一般的なメールヘッダであるRCPT TOヘッダを使用する。
【０１０１】
また、前記ではRCPT TOヘッダ単独で判断することを説明したが、ユーザ管理ディレクトリに各ユーザ毎の誤配信防止の要否を指定することで、送信メールのRCPT TOヘッダとMAIL FROMヘッダから判断することも可能となる。
【０１０２】
つまり、同じ外部の宛先にメールを送信する場合でも、機密情報を送るAさんは誤配信防止の対象とし、機密情報を送らないBさんは誤配信防止の対象としないといった対応が可能となり、より柔軟性を持った機能実現が可能となる。
・保留中メールの特定に承認者が送信するメール本文中に記載される承認キーワードを使用することで、特別なクライアントシステムを必要とせず、安全に承認対象のメールを特定することができる。
・保留中メールを承認するか禁止するかの指示には、承認者が送信するメール本文中に記載される承認か禁止かを示す文字列を使用する。
・メールクライアント側で関連するメールをスレッド表示して参照するには、誤配信防止装置から通知するメールにもRFC822で規定されている一般的なメールヘッダであるReferencesヘッダとIn-Reply-Toヘッダを指定することで実現可能であるが、さらに、誤配信防止装置から通知するメールのSubjectヘッダの前部を対象送信メールのSubjectヘッダの内容と同じものとすることで、メールクライアントでSubject内容によるソートを行ったときに、関連するメールを全てまとめて確認することが可能となる。
【０１０３】
Subjectヘッダの内容でソートを行う際の、Subjectヘッダの設定例を以下に示す。
(例)
それぞれのメールのSubjectヘッダを以下とすることで、ソート表示した場合に関連するメールのみをまとめて参照することができる。
【０１０４】
対象送信メールのSubjectヘッダ
Subject : 来週の打ち合わせの件
誤配信防止装置が送信する承認依頼メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認依頼）
Subject : 来週の打ち合わせの件（2010年12月1日 12:34:56 承認依頼）
誤配信防止装置が送信する禁止結果の通知メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認結果 -禁止）
Subject : 来週の打ち合わせの件（2010年12月1日 13:12:34 承認結果 -禁止）
誤配信防止装置が送信する承認結果の通知メールのSubjectヘッダ （対象メールのSubjectヘッダ + 日付 + 承認結果 - 承認）
Subject : 来週の打ち合わせの件（2010年12月2日 10:01:12 承認結果 - 承認）
◆保留メール承認時の詐称防止装置
承認者からの依頼回答メールを受信した誤配信防止装置では、以下の２段階の方法で承認者の正当性を確認することが可能となる。
【０１０５】
以下の方法で不正な承認者と判断された場合には、承認手続きを行わないことで成りすまし等による承認手続きの詐称防止を実現する。
・ユーザIDと、依頼回答メールに設定されているMAIL FROMヘッダの対応チェック
まず依頼回答メールに記述されている承認キーワードを復号化し、中に含まれるユーザIDを取り出す。次に、前記で取得されたユーザIDから対応するユーザ情報管理ディレクトリを決定する。承認手続きが送信者自身による自己承認の場合は、前記で決定されたユーザ情報管理ディレクトリに含まれるメールアドレス属性と依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダの内容を比較し、第三者による承認手続きの場合は、前記で決定されたユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダの内容を比較し、それぞれ比較結果が一致する場合には、次の承認キーワードと依頼回答メールに設定されているMAIL FROMヘッダの対応チェックを行う。一致しない場合には、配信を禁止する。
・承認キーワードと、依頼回答メールに設定されているMAIL FROMヘッダの対応チェック
前記と同様に、承認キーワードを復号化し、中に含まれるユーザIDを取り出す。次に、取り出されたユーザIDに対応するユーザ情報管理ディレクトリから、送信メール管理データベース格納場所を取得する。送信メール管理データベースから、依頼回答メールに記述されている承認キーワードに対応するレコードを取り出し、そこに登録されている承認者のメールアドレスを取り出す。ここで取り出された承認者のメールアドレスと、依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致するか比較することで承認者の正当性をチェックする。正当でなかったら配信を禁止する。
【０１０６】
なお、図７では承認者のメールアドレスのフィールドは省略しているが、図５を用いて説明した方法で承認依頼メールを作成する際に、承認者のメールアドレス（承認依頼メールのメールヘッダであるToヘッダ及びRCPT TOヘッダに設定するメールアドレス）を送信メール管理データベースに登録することで本手順を実現する。
【０１０７】
以上説明したように、本実施形態によれば、以下に記載するような効果を奏する。
【０１０８】
第１の効果は、承認及び禁止の手続きを普段利用している汎用のメールクライアントを使用して実施できることである（汎用性の向上）。
【０１０９】
その理由は、まず、承認及び禁止の手続きが全てメール送信により実現可能であることである。また、その理由は、承認手続きに承認／禁止コマンドを使用し、依頼回答メールにReferencesヘッダやIn-Reply-Toヘッダを使用しないことである。
【０１１０】
第２の効果は、承認手続きで対象のメールを一意に特定することができ、成りすましによる不正承認などセキュリティ上のリスクを低減することができることである（安全性の向上）。
【０１１１】
その理由は、承認及び禁止の手続きにメールIDを使用せず、ユーザIDやメールを一意に特定する情報を暗号化した承認キーワードをメール本文に記述して使用することである。
【０１１２】
第３の効果は、メール配信の禁止通知を受信したユーザが禁止された理由を速やかに認識できることである（利便性の向上）。
【０１１３】
その理由は、承認者が依頼回答メールで禁止理由を通知し、その禁止理由を元の発信者への結果通知メールで通知できることである。配信を禁止する理由には宛先アドレスの誤りや本文や添付ファイルに機密情報を含んでいるなど数多く考えられるが、発信者に禁止理由を通知することで発信者は速やかに問題点を認識することができ、発信者と承認者との不要なやり取りなどに費やされる手間や時間を削減することができる。
【０１１４】
第４の効果は、ユーザのメールクライアントで関連するメールをスレッド表示して参照することができ、まだ結果が返ってきていないメールや禁止されたメール、元メールの情報を容易に確認可能となることにある（利便性の向上）。
【０１１５】
その理由は、誤配信防止装置から送信する承認依頼メールや承認結果通知メールにReferencesヘッダ、In-Reply-Toヘッダを付与することにある。
【０１１６】
第５の効果は、各通知メールに元メール及び元メールへの添付ファイルを添付していると通知メールの容量が大きくなり過ぎることがあるが、その場合に、ユーザ単位で元メールへの添付ファイルを通知メールに添付しないようにしたり、元メールを通知メールに添付しないようにしたりすることで、よりユーザの環境に合わせた自由な利用が可能になることである（利便性の向上）。
【０１１７】
その理由は、誤配信防止装置から送信する承認依頼メールや依頼回答メールに承認対象の元メール自身や元メールへの添付ファイルを含めるか否かをユーザ毎に設定可能なことである。
【０１１８】
第６の効果は、承認者が承認依頼に対して回答する際に承認の場合、禁止の場合によってそれぞれ回答宛先を意識する必要がなく、宛先誤りによる意図しない承認や禁止を防止できることにある（安全性の向上）。
【０１１９】
その理由は、承認依頼通知に対する依頼回答メールの宛先としてはシステムで決められた唯一の固定メールアドレスを使用することである。
【０１２０】
［実施形態２］
本実施形態による誤配信防止装置は、承認者を発信者自身とすることで、メールを外部に送信する際の自己承認の手段として利用することが出来る。
【０１２１】
承認者を発信者自身とするか又は第三者とするかを示す情報をユーザ管理ディレクトリ２３１（図２参照）の自己承認実施要否（Ｄ１１）及び第三者承認実施要否（Ｄ１２）に登録する。例えば、自己承認で承認されたメールについて、再度第三者である承認者に承認依頼を行い、発信者自身及び第三者による承認が完了した時点で元の宛先に対してメール配信を行う２段階の承認手順を行うことができる。また、自己承認のみを行い第三者による承認は行わないといった運用も採用することができる。
【０１２２】
上述した発信者自信及び第三者による２段階の承認手順の流れを、図１２に示す。
【０１２３】
［実施形態３］
また、実施形態１では誤配信防止の承認者を一名のみとしていたが、図１３の承認者メールアドレスＦ１に示すように、複数の承認者のメールアドレスを指定することができる。
【０１２４】
複数の承認者を指定することで、誰か一人でも承認したら対象メールの配信を行う論理和条件方法や、指定された承認者全員が承認しないと対象メールの配信を行わない論理積条件方法、または、指定された承認者の半数以上が承認した場合に対象メールの配信を行う多数決方法などを適用することができる。
【０１２５】
論理和条件方法を使用することによる効果は、承認者を複数指定することにより、或る承認者が不在でも別の承認者によって承認手続きを進めることができるようになることにある。また、論理積条件方法や多数決方法を使用することによる効果は、稟議目的のメールや予算書等重要要件について複数名の承認判定を必要とすることで機密情報流出のリスクを低減できることにある。
【０１２６】
各利用者毎に論理和条件方法を使用するか、論理積条件方法を使用するか、多数決方法を使用するかを指定するための設定情報をユーザ管理ディレクトリ２３１に保持することができる。論理積条件方法の場合は、一部の承認者から依頼回答メールがあった時点で直ぐにメールの配信を承認するのか禁止するのかを決定するのではなく、全ての承認者からの依頼回答メールが揃うまで各承認者からの結果を送信メール管理データベース２３２に保存し、全ての承認者からの依頼回答メールが揃ってから、承認あるいは禁止の判定を行うこととする。多数決方法の場合は、一部の承認者から依頼回答メールがあった時点で直ぐにメールの配信を承認するのか禁止するのかを決定するのではなく、多数決に必要な数の承認者からの依頼回答メールが揃うまで各承認者からの結果を送信メール管理データベース２３２に保存し、多数決に必要な数の承認者からの依頼回答メールが揃ってから、承認あるいは禁止の判定を行うこととする。
【０１２７】
具体的には、各利用者毎に論理和条件方法、論理積条件方法、多数決方法のうちのどれを使用するかに関する設定情報を、図１３の第三者承認方法Ｆ２に設定すればよく、各承認者からの結果は図１４の承認者メールアドレスの回答Ｇ２に保存すればよい。
【０１２８】
また、図１４の承認者数Ｇ１には、送信メール管理データベース２３２のレコード作成時に、図１３の承認者メールアドレスＦ１に設定されている承認者メールアドレスの数を設定する。
【０１２９】
承認者メールアドレスの回答Ｇ２には、承認者毎に承認か禁止かを表す情報（フラグなど）を保存することとし、ここに保存された情報と承認者数Ｇ１に基づいて、論理和方法、論理積方法又は多数決方法に従った許諾又は禁止の判定を行う。
【０１３０】
つまり、論理積条件方法の場合は、承認者メールアドレスＧ２の承認か禁止を表す情報が全て承認を示せば対象のメールの配信は承認されたと判定し、多数決方法の場合は、承認を示している情報に対応する承認者メールアドレスＧ２の数が過半数であれば承認されたと判定する。
【０１３１】
なお、承認者として複数名を指定した場合は承認依頼メール１２１と通知メール１２３の宛先には指定されている全ての承認者のメールアドレスを含むことで、全承認者が共通して対象のメールの承認状況を確認できるものとする。
【０１３２】
誤配信防止装置の各部は、ハードウェアによって構成することもできるが、その一部又は全部をソフトウェアによって構成することもできる。ここで、ソフトウェアによって構成するとは、コンピュータをその部分として機能させるためのプログラムをコンピュータが読み込んで実行することにより構成することを意味する。
【０１３３】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１３４】
（付記１）
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
を備えることを特徴とするメール誤配信防止装置。
【０１３５】
（付記２）
付記１に記載のメール誤配信防止装置であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段をさらに備えるメール誤配信防止装置。
【０１３６】
（付記３）
付記１又は２に記載のメール誤配信防止装置であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３７】
（付記４）
付記１乃至３の何れか１に記載のメール誤配信防止装置であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３８】
（付記５）
付記１乃至４の何れか１に記載のメール誤配信防止装置であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１３９】
（付記６）
付記１乃至５の何れか１に記載のメール誤配信防止装置であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【０１４０】
（付記７）
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
を備えることを特徴とするメール誤配信防止装置。
【０１４１】
（付記８）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認するメール誤配信防止方法。
【０１４２】
（付記９）
付記８に記載のメール誤配信防止方法であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４３】
（付記１０）
付記８又は９に記載のメール誤配信防止方法であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４４】
（付記１１）
付記８乃至１０の何れか１に記載のメール誤配信防止方法であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４５】
（付記１２）
付記８乃至１１の何れか１に記載のメール誤配信防止方法であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４６】
（付記１３）
付記８乃至１２の何れか１に記載のメール誤配信防止方法であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、対象となっているメールの配信を禁止するステップを更に有することを特徴とするメール誤配信防止方法。
【０１４７】
（付記１４）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４８】
（付記１５）
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【０１４９】
（付記１６）
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
として機能させるためのメール誤配信防止プログラム。
【０１５０】
（付記１７）
付記１６に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワード及び禁止を表す所定のデータが含まれている場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５１】
（付記１８）
付記１６又は１７に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５２】
（付記１９）
付記１６乃至１８の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５３】
（付記２０）
付記１６乃至１９の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５４】
（付記２１）
付記１６乃至２０の何れか１に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【０１５５】
（付記２２）
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
として機能させるためのメール誤配信防止プログラム。
【産業上の利用可能性】
【０１５６】
本発明は、メールの誤配信を問題とする全ての分野で利用可能である。
【０１５７】
企業等の保持するメールサーバに本発明の技術を組み込むことで、利用者端末には影響を与えず誤配信防止の仕組みを適用させることが可能となる。
【符号の説明】
【０１５８】
１ メールクライアント
２ 誤配信防止装置
４ メールクライアント
２１ 承認依頼処理部
２２ 承認処理部
２３ データ領域
１１１オリジナルメール（誤配信防止対象メール）
１２１ 承認依頼メール
１２２ 依頼回答メール
１２３ 通知メール
【特許請求の範囲】
【請求項１】
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
を備えることを特徴とするメール誤配信防止装置。
【請求項２】
請求項１に記載のメール誤配信防止装置であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段をさらに備えるメール誤配信防止装置。
【請求項３】
請求項１又は２に記載のメール誤配信防止装置であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項４】
請求項１乃至３の何れか１に記載のメール誤配信防止装置であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項５】
請求項１乃至４の何れか１に記載のメール誤配信防止装置であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項６】
請求項１乃至５の何れか１に記載のメール誤配信防止装置であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項７】
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
を備えることを特徴とするメール誤配信防止装置。
【請求項８】
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【請求項９】
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
として機能させるためのメール誤配信防止プログラム。
【請求項１０】
請求項９に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワード及び禁止を表す所定のデータが含まれている場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【請求項１】
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
を備えることを特徴とするメール誤配信防止装置。
【請求項２】
請求項１に記載のメール誤配信防止装置であって、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段をさらに備えるメール誤配信防止装置。
【請求項３】
請求項１又は２に記載のメール誤配信防止装置であって、
前記承認キーワードは、更にユーザＩＤ及びメール固有情報を含み、前記依頼回答メールに含まれる前記承認キーワードに含まれるユーザＩＤにより特定される場所に格納されているメールの中から、前記依頼回答メールに含まれるメール固有情報により特定されるメールを対象となっているメールとして配信する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項４】
請求項１乃至３の何れか１に記載のメール誤配信防止装置であって、
前記承認者が送信者である自己承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれるメールアドレス属性と前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項５】
請求項１乃至４の何れか１に記載のメール誤配信防止装置であって、
第三者による承認の場合であって、前記依頼回答メールに記述されている前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリに含まれる承認者メールアドレス属性に含まれるメールアドレスと前記依頼回答メールのメールヘッダに設定されているMAIL FROMヘッダとが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項６】
請求項１乃至５の何れか１に記載のメール誤配信防止装置であって、
前記承認キーワードに含まれているユーザＩＤに対応するユーザ情報管理ディレクトリから送信メール管理データベース格納場所を取得し、送信メール管理データベースから前記依頼回答メールに記述されている前記承認キーワードに対応するレコードを取り出し、そこに登録されている前記承認者のメールアドレスと、前記依頼回答メールに設定されているMAIL FROMヘッダのメールアドレスが一致しない場合には、前記対象メールの配信を禁止する手段を更に備えることを特徴とするメール誤配信防止装置。
【請求項７】
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止する手段と、
を備えることを特徴とするメール誤配信防止装置。
【請求項８】
承認者に承認キーワードを含む承認依頼メールを送信し、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認し、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び禁止を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を禁止するメール誤配信防止方法。
【請求項９】
メール誤配信防止装置としてコンピュータを機能させるためのメール誤配信防止プログラムであって、
前記コンピュータを、
承認者に承認キーワードを含む承認依頼メールを送信する手段と、
前記承認依頼メールに対応することが想定されている依頼回答メールを受信する手段と、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた前記承認キーワード及び承認を表す所定のデータが含まれている場合には、誤配信防止の対象となっている対象メールの配信を承認する手段と、
として機能させるためのメール誤配信防止プログラム。
【請求項１０】
請求項９に記載のメール誤配信防止プログラムであって、
コンピュータを、
前記依頼回答メールに、該依頼回答メールに対応する承認依頼メールに含まれていた承認キーワード及び禁止を表す所定のデータが含まれている場合には、前記対象メールの配信を禁止する手段として更に機能させるためのメール誤配信防止プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１３−１０２５３９（Ｐ２０１３−１０２５３９Ａ）
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【出願番号】特願２０１３−２４８９４（Ｐ２０１３−２４８９４）
【出願日】平成２５年２月１２日（２０１３．２．１２）
【分割の表示】特願２０１１−２７２０８（Ｐ２０１１−２７２０８）の分割
【原出願日】平成２３年２月１０日（２０１１．２．１０）
【出願人】（３９０００１３９５）ＮＥＣシステムテクノロジー株式会社 (438)
【Ｆターム（参考）】
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【出願日】平成２５年２月１２日（２０１３．２．１２）
【分割の表示】特願２０１１−２７２０８（Ｐ２０１１−２７２０８）の分割
【原出願日】平成２３年２月１０日（２０１１．２．１０）
【出願人】（３９０００１３９５）ＮＥＣシステムテクノロジー株式会社 (438)
【Ｆターム（参考）】
[ Back to top ]