JP2014228955A - メールチェックプログラム、メールチェック装置及びメールチェックシステム - Google Patents

Abstract

【課題】初回受信時の過剰アラートを抑制できるメールチェックプログラム等を提供する。【解決手段】メールチェックプログラムは、第１のアドレスおよび第２のアドレスを宛先に含む受信メールの第１のアドレスと、受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、受信メールに対する処理を実行する。メールチェックプログラムは、当該処理に関する情報を第２のアドレスに送信する。また、メールチェックプログラムは、通信履歴が所定の基準を満たさない場合に、第２のアドレスから受信した、受信メールに対して実行された処理に関する情報に基づいて、受信メールに対する処理を実行する。【選択図】図１

Description

本発明は、メールチェックプログラム、メールチェック装置及びメールチェックシステムに関する。

近年、情報の価値が一層高まるに伴って、機密情報の窃取を目的として特定の組織の端末にウイルスメールを送付する標的型メール攻撃等、悪意のある電子メールによる攻撃が増加している。この様な悪意のある電子メールによる攻撃から端末を守るために、端末でユーザが電子メール（以下、単にメールという）を開封する前に、受信したメールが悪意のあるメールであるか否かを検証するメールチェッカが知られている。端末にインストールされたメールチェッカは、信頼できる送信者の送信元アドレス等を記録したホワイトリストを持つ。メールチェッカは、受信したメールの送信元アドレスがホワイトリストに登録されている場合、受信したメールは安全であると判断する。メールチェッカは、受信したメールの送信元アドレスがホワイトリストに登録されていない場合、端末のユーザに対してアラートを発する。

特開２００９−１７５９００号公報

「メール誤送信防止ソリューション−ShieldMailChecker−」パンフレット、株式会社富士通ソーシアルサイエンスラボラトリ、２０１２年発行 「標的型メールへのクライアント対策技術」パンフレット、富士通株式会社、２０１２年１０月発行 "業界初！標的型メール攻撃を端末側でリアルタイムに検知・警告する技術を開発"、［Online］，［平成２５年１月２８日検索］、インターネット＜http://pr.fujitsu.com/jp/news/2012/05/15-3.html＞ 吉岡孝司、片山佳則、津田宏、森永正信、深澤亮太著、「電子メールの特徴情報を用いた標的型メールへのクライアント対策技術の提案」情報処理学会研究報告Vol.2012-CSEC-58 No.37、２０１２年７月２０日発行

しかしながら、受信したメールの送信元アドレスがホワイトリストに登録されていない場合、例えば、当該端末で初めて受信する場合、ユーザが信頼する送信者からのメールであっても、メールチェッカはアラートを発してしまう。

１つの側面では、本発明は、初回受信時の過剰アラートを抑制できるメールチェックプログラム、メールチェック装置及びメールチェックシステムを提供することにある。

１つの実施態様では、メールチェックプログラムは、第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行する。また、メールチェックプログラムは、当該処理に関する情報を前記第２のアドレスに送信する。また、メールチェックプログラムは、前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行する。

初回受信時の過剰アラートを抑制できる。

図１は、本発明の一例を示す説明図である。 図２は、本実施例の端末のハードウエア構成の一例を示すブロック図である。 図３は、本実施例の端末の機能構成の一例を示すブロック図である。 図４は、信頼度判定の一例を示す説明図である。 図５は、信頼度判定の他の一例を示す説明図である。 図６は、信頼度判定の他の一例を示す説明図である。 図７は、処理情報を提供する側のメールチェッカの動作の一例を示すフローチャートである。 図８は、処理情報の提供を受ける側のメールチェッカの動作の一例を示すフローチャートである。 図９は、本実施例のメールチェックシステムの動作の一例を示す説明図である。 図１０は、本実施例のメールチェックシステムの動作の一例を示すシーケンス図である。 図１１は、本実施例のメールチェックシステムの処理情報のやり取りの一例を示す説明図である。

以下、図面に基づいて、本願の開示するメールチェックプログラム、メールチェック装置及びメールチェックシステムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。また、以下の実施例は、矛盾しない範囲で適宜組みあわせてもよい。

まず、図１を用いて本発明の概略を説明する。図１は、本発明の一例を示す説明図である。図１は、Ａさん、Ｂさん、Ｃさん及びＤさんを宛先とした同報メールを受信した場合を示す。当該同報メールは、第１のアドレスおよび第２のアドレスを宛先に含む受信メールであり、ＴｏやＣｃ等の宛先種別に複数の宛先があるメールである。Ａさん〜Ｄさんの端末には、端末でユーザがメールを開封する前に、受信したメールが悪意のあるメール（成りすましメール）であるか否かを検証するメールチェッカが導入されている。ここで、端末には、例えば、クライアントＰＣを用いることができるが、スマートフォン等のメールが受信できる端末であれば、いずれも用いることができる。

Ａさん〜Ｄさんの各メールチェッカは、当該同報メールを受信すると、ポリシー設定等が格納されているポリシー設定等データベース（ＤＢ）等を参照して、それぞれ処理結果を生成する。各メールチェッカは、チェッカ導入データベース（ＤＢ）を参照して、メールチェッカを導入している同報メールの受信者のメールチェッカに対して、処理結果を提供する。例えば、Ａさん〜Ｃさんが先に同報メールを処理して開封した場合、ＤさんはＡさん〜Ｃさんの処理結果を参照することができる。

この様に、メールチェッカを導入している受信者が、お互いに処理結果を提供する。これにより、初めて受信する送信者からのメールに対して、他の同報メールの受信者が安全であると確認した処理結果を受信した場合には、アラートの発報を抑えることができる。

図２は、本実施例の端末のハードウエア構成の一例を示すブロック図である。図２に示す端末１は、プロセッサ１１と、メモリ１２と、表示部１３と、操作部１４と、補助記憶装置１５と、ネットワークインタフェース１６とを有する。プロセッサ１１は、端末１全体を制御するものである。メモリ１２は、各種プログラムの各種情報を記憶するものである。表示部１３は、各種情報をユーザに表示する。表示部１３は、例えば、液晶表示装置である。操作部１４は、ユーザからの入力を受け付ける。操作部１４は、例えば、キーボード、マウス及びタッチパネル等である。補助記憶装置１５は、後述する履歴データベース（以下、履歴ＤＢと称する）等のメールに関わる各種情報を記憶する。補助記憶装置１５は、例えば、フラッシュメモリである。ネットワークインタフェース１６は、構内ＬＡＮ及びインターネット等のネットワークと接続する通信インタフェースである。

図３は、本実施例の端末の機能構成の一例を示すブロック図である。プロセッサ１１は、メモリ１２に格納されたプログラムに基づき各種プロセスとなる機能を構成する。プロセッサ１１は、本実施例のメールチェッカ１０として、メール受信部２０と、関係判定部２１と、チェック部２２と、アラート処理部２３と、メール処理部２４と、処理情報送信部２５と、信頼度判定部２６と、記憶部２７とを機能する。記憶部２７は、履歴ＤＢ２８、ポリシー設定２９、信頼度情報データベース（以下、信頼度情報ＤＢと称する）３０及びチェッカ導入データベース（以下、チェッカ導入ＤＢと称する）３１等を管理するものである。また、プロセッサ１１は、メーラー４０と、アウトバンド処理部４１とを機能する。アウトバンド処理部４１は、その一部としてアウトバンドホワイトリストデータベース（以下、アウトバンドホワイトリストＤＢと称する）４２を管理するものである。なお、以下の説明では、第１のアドレスをユーザの宛先とし、第２のアドレスを他のユーザの宛先として説明する。

メール受信部２０は、ネットワークインタフェース１６を通じて、ネットワークと接続する。メール受信部２０は、ネットワーク上の送信元から送信されたメールを受信する。また、メール受信部２０は、他の端末１のメールチェッカ１０からメールとして送信される、処理に関する情報である処理情報を受信する。メールのプロトコルとしては、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を用いることができる。メール受信部２０は、受信メールを関係判定部２１に送信するとともに、履歴ＤＢ２８に格納する。また、メール受信部２０は、処理情報をチェック部２２及び信頼度判定部２６に出力する。

関係判定部２１は、メール受信部２０から受信メールが入力される。関係判定部２１は、受信メールのヘッダ情報と履歴ＤＢ２８を参照し、受信メールの送信元アドレスの送信者と、第１のアドレスであるユーザの宛先、つまり端末１のユーザである受信者との関係を判定する。関係判定部２１は、例えば、受信メールの宛先の受信者が、過去に当該送信元アドレスの送信者からのメールを受信した通信履歴を有する場合には、送信元の送信者と宛先の受信者とは、所定の基準を満たすと判定する。つまり、この場合の所定の基準は、受信メールの第１のアドレスの受信者が、過去に当該送信元アドレスの送信者からのメールを受信したか否かとなる。関係判定部２１は、送信者と受信者との間の通信履歴が所定の基準を満たすと判定した場合、受信メールを関係あり情報とともに、チェック部２２に出力する。また、関係判定部２１は、信頼度判定部２６に関係あり情報を出力する。

また、関係判定部２１は、例えば、受信メールの宛先の受信者が、過去に当該送信元の送信者からのメールを受信したことがない場合には、送信元アドレスの送信者と第１のアドレスである宛先の受信者とは、通信履歴が所定の基準を満たさないと判定する。関係判定部２１は、送信者と受信者との通信履歴が所定の基準を満たさないと判定した場合、受信メールを関係なし情報とともに、チェック部２２に出力する。また、関係判定部２１は、信頼度判定部２６に関係なし情報を出力する。ここで、受信メールのヘッダ情報は、送信元（Ｆｒｏｍ等）、宛先種別（Ｔｏ、Ｃｃ等）、表題（Ｓｕｂｊｅｃｔ）、送信日時（Ｄａｔｅ）、メッセージＩＤ（Ｍｅｓｓａｇｅ−Ｉｄ）等を有する。

チェック部２２は、関係判定部２１から受信メール、及び、関係あり情報又は関係なし情報が入力される。また、チェック部２２は、メール受信部２０から処理情報が入力される。チェック部２２は、関係あり情報が入力された場合、つまり、受信メールの送信元の送信者と宛先の受信者との間の通信履歴が所定の基準を満たす場合、受信メールがメールチェッカ１０によるチェックの対象であるか否かを判定する。チェック部２２は、受信メールに、例えば、ＵＲＬ及び添付ファイルのうち１以上が存在すれば、メールチェッカ１０によるチェックの対象であると判定する。チェック部２２は、チェックの対象である場合、受信メールをアラート処理部２３に出力する。また、チェック部２２は、例えば、受信メールがテキストメッセージのみである場合には、チェック対象外と判定する。チェック部２２は、チェック対象外の場合、受信メールを処理情報送信部２５に出力する。

チェック部２２は、関係なし情報が入力された場合、つまり、受信メールの送信元の送信者と宛先の受信者との間の通信履歴が所定の基準を満たさない場合、受信メールがメールチェッカ１０によるチェックの対象であるか否かを判定する。チェック部２２は、受信メールに、例えば、ＵＲＬ及び添付ファイルのうち１以上が存在すれば、メールチェッカ１０によるチェックの対象であると判定する。チェック部２２は、チェックの対象である場合、受信メールの第２のアドレス（他のユーザの宛先）、つまり、同報宛先の受信者である同報受信者が使用する端末１のメールチェッカ１０からの処理情報を、メール受信部２０が受信するのを待機する。チェック部２２は、メール受信部２０から処理情報を受信すると、受信メールを信頼度判定部２６に出力する。また、チェック部２２は、例えば、受信メールがテキストメッセージのみである場合には、チェック対象外と判定する。チェック部２２は、チェック対象外の場合、受信メールを処理情報送信部２５に出力する。

アラート処理部２３は、チェック部２２から受信メールが入力される。また、アラート処理部２３は、信頼度判定部２６から受信メール及び処理情報が入力される。アラート処理部２３は、受信メールがメールチェッカ１０によるチェックの対象である場合、処理情報を取得又は生成する。アラート処理部２３は、ポリシー設定２９に格納されているホワイトリスト及びポリシー設定を参照する。アラート処理部２３は、当該送信元のアドレスがホワイトリストに登録されている、又は、ポリシー設定に適合する場合には、受信者であるユーザに対して警告を発せず、スルー処理としてスルー情報を生成する。ここで、アラート処理部２３は、アウトバンドホワイトリストＤＢ４２に格納されているアウトバンドホワイトリストを参照してもよい。アラート処理部２３は、当該送信元のアドレスが、アウトバンドホワイトリストに登録されている場合にも、受信者であるユーザに対して警告を発せず、スルー処理としてスルー情報を生成する。更に、アラート処理部２３は、ホワイトリスト及びポリシー設定に加えて、送受信で互いに付与する識別子、及び、履歴ＤＢ２８に格納されている過去の受信メールの経路等のヘッダ情報等を参照してもよい。

アラート処理部２３は、当該送信元のアドレスがホワイトリストに登録されていない場合、又は、処理情報を受信した場合には、受信者であるユーザに対して警告を発するアラート処理を行う。アラート処理は、受信メールの少なくとも一部、例えば、本文の冒頭等、並びに、ＵＲＬ及び添付ファイルのうち１以上に関する情報を、表示部１３にポップアップ画面等で表示して、当該受信メールの受信者であるユーザに対して情報を提示する。アラート処理部２３は、ポップアップ画面内等に、当該受信メールを安全化するか否かの選択肢を併せて表示し、ユーザの選択を促す。ユーザは、操作部１４を操作して、当該受信メールを安全化するか否かを選択する。なお、このとき、表示部１３に、他のユーザの宛先における当該受信メールに対する処理の処理情報を表示してもよい。

アラート処理部２３は、操作部１４の操作情報に基づき、安全化を行う旨の安全化情報、又は、受信メールに対してユーザがそのまま受信する確認を行った旨の確認済情報を取得する。アラート処理部２３は、取得又は生成した安全化情報、確認済情報或いはスルー情報を処理情報として、受信メールとともにメール処理部２４に出力する。なお、アラート処理は、安全化の他に、受信メールを特殊フォルダに隔離する旨の隔離情報を、処理情報としてメール処理部２４に出力するようにしてもよい。

メール処理部２４は、アラート処理部２３又は信頼度判定部２６から、受信メール、及び、処理情報として、安全化情報、確認済情報又はスルー情報が入力される。メール処理部２４は、入力された安全化情報、確認済情報又はスルー情報に基づいて、受信メールを処理する。

メール処理部２４は、安全化情報が入力された場合、入力された安全化情報に基づいて安全化処理を行う。安全化処理は、例えば、受信メールに対して、ＵＲＬ及び添付ファイルのうち１以上を除去する。ここで、安全化処理は、例えば、ＵＲＬ及び添付ファイルのうち、どちらかを除去してもよいし、両方とも除去してもよい。また、ＵＲＬの安全化処理は、例えば、悪意があると疑われるキーワードを含むＵＲＬ、及び、短縮ＵＲＬ等を除去する。また、添付ファイルの安全化処理は、例えば、実行ファイル、圧縮ファイル、文書ファイル、及び、画像ファイル等の添付ファイルを除去する。

メール処理部２４は、確認済情報又はスルー情報が入力された場合、そのまま確認済情報又はスルー情報を処理情報として、受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、安全化処理が完了したときは安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。さらに、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。なお、メール処理部２４は、隔離情報が入力された場合には、受信メールを特殊フォルダに隔離する隔離処理を行うようにしてもよい。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、当該受信メールの同報受信者（他のユーザの宛先）のうち、メールチェッカ１０を導入している同報受信者の端末１に対して、処理情報を、ネットワークインタフェース１６を通じて送信する。処理情報送信部２５は、処理情報の送信が完了すると、受信メールをメーラー４０に出力する。

また、処理情報送信部２５は、チェック部２２から受信メールが入力される。この場合、処理情報送信部２５は、受信メールの他のユーザの宛先に対して処理情報を送信せず、受信メールをメーラー４０に出力する。また、処理情報送信部２５は、メールチェッカ１０が処理情報の提供を受ける側であり、かつ、提供を受けた処理情報が信頼度ありの場合は、受信メールの他のユーザの宛先に対して処理情報を送信せず、受信メールをメーラー４０に出力する。

信頼度判定部２６は、関係判定部２１から関係なし情報が入力された場合、他のユーザの宛先から受信した処理情報がメール受信部２０から入力される。信頼度判定部２６は、履歴ＤＢ２８及び信頼度情報ＤＢ３０を参照し、受信メールの他のユーザの宛先である同報受信者の情報に基づいて、処理情報の信頼度を判定する。信頼度判定部２６は、信頼度ありと判定した場合、受信メール及び処理情報をメール処理部２４に出力する。信頼度判定部２６は、信頼度なしと判定した場合、受信メール及び処理情報をアラート処理部２３に出力する。ここで、信頼度の判定において、送受信で互いに付与する識別子、及び、履歴ＤＢ２８に格納されている過去の受信メールの経路等のヘッダ情報等を参照してもよい。また、信頼度判定部２６は、処理情報を信頼度情報ＤＢ３０に格納する。

また、信頼度判定部２６は、処理情報の信頼度の判定について、他のユーザの宛先の処理情報の分布を、ユーザの宛先の受信者である当該ユーザに提供して判定を促してもよい。また、信頼度判定部２６は、処理情報の信頼度の判定について、予め定めた割合以上の判定結果の処理情報が得られた場合には、当該判定結果の処理情報を、ユーザの宛先のメールチェッカ１０で行う処理の処理情報として採用してもよい。

また、信頼度判定部２６は、関係判定部２１から関係あり情報が入力された場合、受信メールがチェック部２２から入力される。信頼度判定部２６は、受信メールの他のユーザの宛先に係る情報を信頼度情報ＤＢ３０に格納する。

ここで、信頼度判定部２６で行う処理情報の信頼度判定の例を説明する。図４は、信頼度判定の一例を示す説明図である。図４の例は、信頼度判定の判定基準として、各端末１のメールチェッカ１０が互いに処理情報を送受信した回数Ｎを用いる。図４における信頼度判定の判定基準は、例えば、Ｎ＝３とする。また、同報受信者であるＡさん、Ｂさん及びＣさんの各端末１のメールチェッカ１０は、互いに処理情報を共有する。このとき、ＡさんとＢさんの間では、過去に処理情報が３回以上送受信されているとする。つまり、メールチェッカ１０の信頼度判定では、ＡさんとＢさんのソーシャルな関係を活用する。信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、ＡさんとＢさんは信頼関係にあると判定する。つまり、信頼度判定部２６は、ＡさんとＢさんの間で送受信される処理情報は、信頼度ありと判定する。これに対し、ＢさんとＣさんの間では、過去に処理情報が３回未満しか送受信されていないとする。信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、ＡさんとＢさんは信頼関係にないと判定する。つまり、信頼度判定部２６は、ＢさんとＣさんとの間で送受信される処理情報は、信頼度なしと判定する。

図５は、信頼度判定の他の一例を示す説明図である。図５の例は、信頼度判定の判定基準として、同報受信者であるＡさん、Ｂさん、Ｃさん及びＤさんの所属グループを用いる。図５における信頼度判定の判定基準は、例えば、同一の所属グループであるか否かとし、所属グループＹには、Ａさん、Ｂさん及びＣさんが含まれ、Ｄさんは含まれないとする。また、同報受信者であるＡさん、Ｂさん及びＤさんの各端末１のメールチェッカ１０は、互いに処理情報を共有する。信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、ＡさんとＢさんは同一の所属グループであるので、信頼関係にあると判定する。つまり、信頼度判定部２６は、ＡさんとＢさんの間で送受信される処理情報は、信頼度ありと判定する。また、信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、Ａさん及びＢさんと、Ｄさんとは同一の所属グループではないので、信頼関係にないと判定する。つまり、信頼度判定部２６は、Ａさん又はＢさんと、Ｄさんとの間で送受信される処理情報は、信頼度なしと判定する。

図６は、信頼度判定の他の一例を示す説明図である。図６の例は、信頼度判定の判定基準として、同報受信者であるＡさん、Ｂさん及びＣさんの役職関係を用いる。図６における信頼度判定の判定基準は、例えば、上司と部下のように役職関係があるか否かとし、ＡさんとＢさんは上司と部下の役職関係にあり、Ｃさんは、Ａさん及びＢさんと役職関係がないとする。また、同報受信者であるＡさん、Ｂさん及びＣさんの各端末１のメールチェッカ１０は、互いに処理情報を共有する。信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、ＡさんとＢさんは上司と部下の役職関係であるので、信頼関係にあると判定する。つまり、信頼度判定部２６は、ＡさんとＢさんの間で送受信される処理情報は、信頼度ありと判定する。また、信頼度判定部２６は、信頼度情報ＤＢ３０を参照して、Ａさん及びＢさんと、Ｃさんとは役職関係がないので、信頼関係にないと判定する。つまり、信頼度判定部２６は、Ａさん又はＢさんとＣさんとの間で送受信される処理情報は、信頼度なしと判定する。

図３の説明に戻って、履歴ＤＢ２８は、過去に受信したメールの履歴を格納する。格納する履歴は、ヘッダ情報を含む受信メールそのものの他に、送信元のアドレス、送信者、送信者の組織及び送信年月日毎の受信メール数等も格納する。また、格納する履歴は、これらの統計情報も格納してもよい。

ポリシー設定２９は、ポリシー設定として、チェック部２２でのチェック対象であるか否かの判定に用いるチェックポリシー、及び、アラート処理部２３で用いる受信用のホワイトリストを格納する。チェックポリシーは、例えば、ＵＲＬ及び添付ファイルのうち１以上が存在すれば、メールチェッカ１０によるチェックの対象とするチェックポリシーとすることができる。ホワイトリストは、例えば、メーリングリストや社外の委員会のメンバー等、素性の明確な送信元アドレスをリストアップしたものである。また、ポリシー設定は、ホワイトリストの他に、例えば、送受信メールに互いに付与する識別子等を用いることができる。

信頼度情報ＤＢ３０は、受信メールの他のユーザの宛先である同報受信者とのメール及び処理情報の送受信履歴、並びに、同報受信者（他のユーザ）の所属グループ及び役職等を格納する。また、信頼度情報ＤＢ３０は、グループウエアやスケジューラ等、共通して利用しているアプリケーションの情報、及び、第三者機関が示す信頼度等を、信頼度判定に用いるために格納してもよい。

チェッカ導入ＤＢ３１は、メールチェッカ１０が導入済みである端末１を用いる各ユーザの宛先を格納する。つまり、チェッカ導入ＤＢ３１は、受信メールに対する処理情報を共有可能な他のユーザの宛先を格納する。

メーラー４０は、メールチェッカ１０から受信メールが入力される。メーラー４０は、端末１のユーザがメールを送受信できるように、ユーザインタフェースを有する。つまり、メーラー４０は、受信メールの閲覧、送信メールの作成等を、ユーザが行うことができる。メーラー４０は、送信メールをアウトバンド処理部４１に出力する。

アウトバンド処理部４１は、メーラー４０から送信メールが入力される。アウトバンド処理部４１は、アウトバンドホワイトリストＤＢ４２を参照し、誤送信等の可能性があれば、端末１のユーザに警告をする。アウトバンド処理部４１は、誤送信等の可能性がなければ、ネットワークインタフェース１６を通じて、送信メールをネットワーク上の宛先に送信する。

アウトバンドホワイトリストＤＢ４２は、送信用のホワイトリストを格納する。送信用のホワイトリストは、受信用のホワイトリストと同様に、例えば、メーリングリストや社外の委員会のメンバー等、素性の明確な宛先をリストアップしたものである。

次に、本実施例のメールチェックシステムの動作について説明する。まず、実施例１のメールチェッカ１０の動作のうち、処理情報を提供する側のメールチェッカ１０について説明する。図７は、処理情報を提供する側のメールチェッカの動作の一例を示すフローチャートである。なお、図７の例では、端末１のユーザは、過去に送信元からのメールを受信したことがあるものとする。

メールチェッカ１０の関係判定部２１は、メール受信部２０が受信した受信メールの送信元とユーザの宛先との間の通信履歴が所定の基準を満たすか否か判定する。関係判定部２１は、端末１のユーザが過去に送信元からのメールを受信したことがあるので、通信履歴が所定の基準を満たすと判定する。関係判定部２１は、受信メールを関係あり情報とともに、チェック部２２に出力する。チェック部２２は、関係判定部２１から受信メール及び関係あり情報が入力される。チェック部２２は、ポリシー設定２９のチェックポリシーを参照して、受信メールがメールチェッカ１０によるチェック対象であるか否かを判定する（ステップＳ１）。チェック部２２は、受信メールがチェック対象であれば（ステップＳ１肯定）、受信メールをアラート処理部２３に出力する。チェック部２２は、受信メールがチェック対象外であれば（ステップＳ１否定）、受信メールを処理情報送信部２５に出力し、処理情報送信部２５がメーラー４０に受信メールを出力する（ステップＳ１７）。

受信メールがチェック対象である場合、アラート処理部２３は、チェック部２２から受信メールが入力され、処理情報を取得又は生成する。アラート処理部２３は、スルー処理を行うか判定するために、ポリシー設定２９に格納されているホワイトリスト及びポリシー設定を参照する（ステップＳ２）。アラート処理部２３は、送信元がホワイトリストに登録されている、又は、ポリシー設定に適合する場合には（ステップＳ２肯定）、宛先のユーザに対して警告を発せず、スルー処理としてスルー情報を生成する（ステップＳ１３）。アラート処理部２３は、メール処理部２４に受信メール及びスルー情報を出力する。

メール処理部２４は、スルー情報をそのまま処理情報として、受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、当該受信メールの他のユーザの宛先（同報受信者）を抽出する（ステップＳ１４）。処理情報送信部２５は、他のユーザの宛先の端末がメールチェッカ１０を導入しているか判定する（ステップＳ１５）。処理情報送信部２５は、メールチェッカ１０を導入している他のユーザの宛先の端末１に対して（ステップＳ１５肯定）、処理情報であるスルー情報を、ネットワークインタフェース１６を通じて送信する（ステップＳ１６）。その後、処理情報送信部２５は、受信メールをメーラー４０に出力する（ステップＳ１７）。処理情報送信部２５は、メールチェッカ１０を導入していない他のユーザの宛先の端末に対して（ステップＳ１５否定）、処理情報であるスルー情報を送信せずに、受信メールをメーラー４０に出力する（ステップＳ１７）。

アラート処理部２３は、送信元がホワイトリストに登録されていない、又は、ポリシー設定に適合しない場合には（ステップＳ２否定）、宛先であるユーザに対して警告を発するアラート処理を行う（ステップＳ３）。アラート処理は、受信メールの少なくとも一部、例えば、本文の冒頭等、並びに、ＵＲＬ及び添付ファイルのうち１以上に関する情報を、表示部１３に表示するポップアップ画面等で、当該受信メールの宛先であるユーザに対して情報を提示する。アラート処理部２３は、ポップアップ画面内等に、当該受信メールを安全化するか否かの選択肢を併せて表示し、ユーザの選択を促す。ユーザは、操作部１４を操作して、当該受信メールを安全化するか否かを選択する（ステップＳ４）。

アラート処理部２３は、操作部１４の操作情報に基づき、安全化を行う旨の安全化情報、又は、受信メールに対してユーザがそのまま受信する確認を行った旨の確認済情報を取得する。アラート処理部２３は、安全化情報を取得した場合（ステップＳ４肯定）、取得した安全化情報を処理情報として、受信メールとともにメール処理部２４に出力する。アラート処理部２３は、確認済情報を取得した場合（ステップＳ４否定）、取得した確認済情報を処理情報として、受信メールとともにメール処理部２４に出力する。

アラート処理部２３が安全化情報を取得した場合、メール処理部２４は、アラート処理部２３から受信メール及び処理情報が入力される。メール処理部２４は、入力された処理情報である安全化情報に基づいて、受信メールに対して、例えば、ＵＲＬ及び添付ファイルのうち１以上を除去する安全化処理を行う（ステップＳ５）。メール処理部２４は、安全化処理が完了すると、安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、当該受信メールの他のユーザの宛先（同報受信者）を抽出する（ステップＳ６）。処理情報送信部２５は、他のユーザの宛先の端末がメールチェッカ１０を導入しているか判定する（ステップＳ７）。処理情報送信部２５は、メールチェッカ１０を導入している他のユーザの宛先の端末１に対して（ステップＳ７肯定）、処理情報である安全化情報を、ネットワークインタフェース１６を通じて送信する（ステップＳ８）。その後、処理情報送信部２５は、受信メールをメーラー４０に出力する（ステップＳ１７）。また、処理情報送信部２５は、メールチェッカ１０を導入していない他のユーザの宛先の端末に対して（ステップＳ７否定）、処理情報である安全化情報を送信せずに、受信メールをメーラー４０に出力する（ステップＳ１７）。

アラート処理部２３が確認済情報を取得した場合、メール処理部２４は、確認済情報に基づいて、受信メールに対して何も行わない（ステップＳ９）。メール処理部２４は、受信した確認済情報をそのまま処理情報として、受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、当該受信メールの他のユーザの宛先（同報受信者）を抽出する（ステップＳ１０）。処理情報送信部２５は、他のユーザの宛先の端末がメールチェッカ１０を導入しているか判定する（ステップＳ１１）。処理情報送信部２５は、メールチェッカ１０を導入している他のユーザの宛先の端末１に対して（ステップＳ１１肯定）、処理情報である確認済情報を、ネットワークインタフェース１６を通じて送信する（ステップＳ１２）。その後、処理情報送信部２５は、受信メールをメーラー４０に出力する（ステップＳ１７）。処理情報送信部２５は、メールチェッカ１０を導入していない他のユーザの宛先の端末に対して（ステップＳ１１否定）、処理情報である確認済情報を送信せずに、受信メールをメーラー４０に出力する（ステップＳ１７）。処理情報を提供する側のメールチェッカ１０の処理によれば、処理情報を他の宛先のメールチェッカ１０に送信することができる。

続いて、実施例１のメールチェッカ１０の動作のうち、処理情報の提供を受ける側のメールチェッカ１０の動作について説明する。図８は、処理情報の提供を受ける側のメールチェッカの動作の一例を示すフローチャートである。なお、図８の例では、端末１のユーザは、過去に送信元からのメールを受信したことがないものとする。

メールチェッカ１０の関係判定部２１は、メール受信部２０が受信した受信メールの送信元とユーザの宛先との間の通信履歴が所定の基準を満たすか否か判定する。関係判定部２１は、端末１のユーザが過去に送信元からのメールを受信したことがないので、通信履歴が所定の基準を満たさないと判定する。関係判定部２１は、受信メールを関係なし情報とともに、チェック部２２に出力する。また、関係判定部２１は、関係なし情報を信頼度判定部２６に出力する。チェック部２２は、関係判定部２１から受信メール及び関係なし情報が入力される。チェック部２２は、ポリシー設定２９のチェックポリシーを参照して、受信メールがメールチェッカ１０によるチェック対象であるか否かを判定する（ステップＳ５１）。チェック部２２は、受信メールがチェック対象であれば（ステップＳ５１肯定）、受信メールをアラート処理部２３に出力する。チェック部２２は、受信メールがチェック対象外であれば（ステップＳ５１否定）、受信メールを処理情報送信部２５に出力し、処理情報送信部２５がメーラー４０に受信メールを出力する（ステップＳ６５）。

受信メールがチェック対象である場合、チェック部２２は、受信メールの他のユーザの宛先のメールチェッカ１０から処理情報が送信されて、メール受信部２０が処理情報を受信するのを待機する。チェック部２２は、メール受信部２０が処理情報を受信すると、受信メールを信頼度判定部２６に出力する（ステップＳ５２）。なお、チェック部２２は、処理情報の受信を待たずに、受信メールを信頼度判定部２６に出力してもよい。この場合、チェック部２２は、信頼度判定部２６に対して、信頼度なし情報を出力する。

信頼度判定部２６は、チェック部２２から受信メールが入力され、処理情報がメール受信部２０から入力される。信頼度判定部２６は、履歴ＤＢ２８及び信頼度情報ＤＢ３０を参照し、受信メールの他のユーザの宛先（同報受信者）の情報に基づいて、処理情報の信頼度を判定する（ステップＳ５３）。信頼度判定部２６は、信頼度ありと判定した場合（ステップＳ５３肯定）、受信メール及び処理情報をメール処理部２４に出力する。信頼度判定部２６は、信頼度なしと判定した場合（ステップＳ５３否定）、受信メール及び処理情報をアラート処理部２３に出力する。また、信頼度判定部２６は、チェック部２２から信頼度なし情報が入力された場合も、信頼度なしと判定する。

信頼度判定部２６が信頼度有りと判定した場合、メール処理部２４は、信頼度判定部２６から受信メール及び処理情報が入力される。メール処理部２４は、入力された処理情報である、安全化情報、確認済情報又はスルー情報に基づいて、受信メールを処理する（ステップＳ５４）。

メール処理部２４は、安全化情報が入力された場合（ステップＳ５４“安全化情報”）、当該安全化情報に基づいて、受信メールに対して安全化処理を行う（ステップＳ５５）。メール処理部２４は、安全化処理が完了すると、安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。

処理情報送信部２５は、メールチェッカ１０が処理情報の提供を受ける側であり、かつ、提供を受けた処理情報が信頼度ありの場合であるので、受信メールの他のユーザの宛先に対して処理情報を送信せず、受信メールをメーラー４０に出力する（ステップＳ６５）。

メール処理部２４は、確認済情報が入力された場合（ステップＳ５４“確認済情報”）、受信メールに対して何も行わない（ステップＳ５６）。ここで、メール処理部２４は、確認済である旨を受信メールに追記する等の処理を行なってもよい。メール処理部２４は、確認済情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。

処理情報送信部２５は、メールチェッカ１０が処理情報の提供を受ける側であり、かつ、提供を受けた処理情報が信頼度ありの場合であるので、受信メールの他の宛先に対して処理情報を送信せず、受信メールをメーラー４０に出力する（ステップＳ６５）。

メール処理部２４は、スルー情報が入力された場合（ステップＳ５４“スルー情報”）、受信メールに対して何も行わない（ステップＳ５７）。メール処理部２４は、スルー情報を処理情報として、受信メールとともに処理情報送信部２５に出力する。

処理情報送信部２５は、メールチェッカ１０が処理情報の提供を受ける側であり、かつ、提供を受けた処理情報が信頼度ありの場合であるので、受信メールの他の宛先に対して処理情報を送信せず、受信メールをメーラー４０に出力する（ステップＳ６５）。

信頼度判定部２６が信頼度なしと判定した場合、アラート処理部２３は、信頼度判定部２６から受信メール及び処理情報が入力される。アラート処理部２３は、宛先であるユーザに対して警告を発するアラート処理を行う（ステップＳ５８）。アラート処理は、受信メールの少なくとも一部、例えば、本文の冒頭等、並びに、ＵＲＬ及び添付ファイルのうち１以上に関する情報を、表示部１３に表示するポップアップ画面等で、当該受信メールの宛先であるユーザに対して情報を提示する。アラート処理部２３は、ポップアップ画面内等に、当該受信メールを安全化するか否かの選択肢を併せて表示し、ユーザの選択を促す。ユーザは、操作部１４を操作して、当該受信メールを安全化するか否かを選択する（ステップＳ５９）。

アラート処理部２３は、操作部１４の操作情報に基づき、安全化を行う旨の安全化情報、又は、受信メールに対してユーザがそのまま受信する確認を行った旨の確認済情報を取得する。アラート処理部２３は、安全化情報を取得した場合（ステップＳ５９肯定）、取得した安全化情報を処理情報として、受信メールとともにメール処理部２４に出力する。アラート処理部２３は、確認済情報を取得した場合（ステップＳ５９否定）、取得した確認済情報を処理情報として、受信メールとともにメール処理部２４に出力する。

アラート処理部２３が安全化情報を取得した場合、メール処理部２４は、アラート処理部２３から受信メール及び処理情報が入力される。メール処理部２４は、処理情報である安全化情報に基づいて、受信メールに対して安全化処理を行う（ステップＳ６４）。メール処理部２４は、安全化処理が完了すると、安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、他のユーザの宛先の端末に対して、処理情報である安全化情報を送信せずに、受信メールをメーラー４０に出力する（ステップＳ６５）。なお、処理情報送信部２５は、処理情報を提供する側と同様に、安全化情報を他のユーザの宛先のメールチェッカ１０に対して送信してもよい。

アラート処理部２３が確認済情報を取得した場合、メール処理部２４は、アラート処理部２３から受信メール及び処理情報が入力される。メール処理部２４は、確認済情報に基づいて、受信メールに対して何も行わない（ステップＳ６０）。メール処理部２４は、受信した確認済情報をそのまま処理情報として、受信メールとともに処理情報送信部２５に出力する。また、メール処理部２４は、処理情報を履歴ＤＢ２８に格納する。

処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、当該受信メールの他のユーザの宛先（同報受信者）を抽出する（ステップＳ６１）。処理情報送信部２５は、他のユーザの宛先の端末がメールチェッカ１０を導入しているか否か判定する（ステップＳ６２）。処理情報送信部２５は、メールチェッカ１０を導入している他のユーザの宛先の端末１に対して（ステップＳ６２肯定）、処理情報である確認済情報を、ネットワークインタフェース１６を通じて送信する（ステップＳ６３）。その後、処理情報送信部２５は、受信メールをメーラー４０に出力する（ステップＳ６５）。処理情報送信部２５は、メールチェッカ１０を導入していない他のユーザの宛先の端末に対して（ステップＳ６２否定）、処理情報である確認済情報を送信せずに、受信メールをメーラー４０に出力する（ステップＳ６５）。処理情報を提供される側のメールチェッカ１０の処理によれば、他のユーザの宛先の処理情報を受信して、メールチェッカ１０の処理に用いることができる。

次に、本実施例のメールチェッカ１０、及び、複数のメールチェッカ１０からなるメールチェックシステムの動作について説明する。図９は、本実施例のメールチェックシステムの動作の一例を示す説明図である。また、図１０は、本実施例のメールチェックシステムの動作の一例を示すシーケンス図である。

図９及び図１０のメールチェックシステムの動作の一例では、送信者Ｘが、受信者Ａ、Ｂ、Ｃ及びＥに対して、メールを送信した場合を説明する。例えば、受信者Ａ、Ｂ及びＣは、メールチェッカ１０が導入された端末１を使用し、受信者Ｅが使用する端末１００には、メールチェッカ１０が導入されていないものとする。ここで、例えば、受信者Ａは、送信者Ｘと過去に多くのメールのやり取り、すなわちメールの送受信があるとする。また、例えば、受信者Ｂは、過去に送信者Ｘ及び受信者Ａとメールのやり取りがないとする。また、例えば、受信者Ｃは、過去に送信者Ｘとメールのやり取りがないが、受信者Ａとはメールのやり取りがあり信頼関係があるとする。また、メールには、メールチェッカ１０のチェック対象となる、例えば、ＵＲＬ及び添付ファイルのうち１以上が存在するものとする。

初めに、送信者Ｘが、宛先種別Ｔｏに受信者Ａ、Ｂ、Ｃ及びＥの宛先を指定して、メールを送信する。受信者Ａ、Ｂ、Ｃ及びＥの端末１及び端末１００に届いた当該メールは、以下の説明では受信メールと称する。なお、受信者Ｅの端末１００は、メールチェッカ１０が導入されていないので、受信メールについての判断は受信者Ｅがメーラー４０上で判断するものとし、動作の説明を省略する。

受信者Ａの端末１のメールチェッカ１０は、受信メールを受信する（ステップＳ１０１）。また、同様に、受信者Ｂ及びＣの端末１のメールチェッカ１０は、受信メールを受信する（ステップＳ１２１、Ｓ１４１）。受信者Ａのメール受信部２０は、受信メールを受信して関係判定部２１に出力する。受信者Ｂ及びＣのメール受信部２０も同様に、受信メールを受信して各関係判定部２１に出力する。

受信者Ａの関係判定部２１は、メール受信部２０から受信メールが入力され、送信者Ｘと受信者Ａとの関係を判定する（ステップＳ１０２）。受信者Ａの関係判定部２１は、受信者Ａは送信者Ｘと過去にメールの送受信履歴があるので、送信者Ｘと受信者Ａとの間の通信履歴が所定の基準を満たすと判定する。受信者Ａの関係判定部２１は、受信メールを関係あり情報とともに、チェック部２２に出力する。

受信者Ｂ及びＣの関係判定部２１は、各メール受信部２０から受信メールが入力され、送信者Ｘと受信者Ｂ又はＣとの関係を判定する（ステップＳ１２２、Ｓ１４２）。受信者Ｂ及びＣの関係判定部２１は、送信者Ｘと受信者Ｂ又はＣとは、過去にメールの送受信がないので、通信履歴が所定の基準を満たさないと判定する。受信者Ｂ及びＣの関係判定部２１は、受信メールを関係なし情報とともに、チェック部２２に出力する。

受信者Ａのチェック部２２は、関係判定部２１から受信メール及び関係あり情報が入力されると、受信メールがメールチェッカ１０によるチェックの対象であるか否かを判定する（ステップＳ１０３）。受信者Ａのチェック部２２は、受信メールにＵＲＬ及び添付ファイルのうち１以上が存在しているので、チェック対象であると判定する（ステップＳ１０３肯定）。受信者Ａのチェック部２２は、受信メールをアラート処理部２３に出力する。なお、図１０では省略したが、チェック部２２は、受信メールがメールチェッカ１０によるチェック対象でない場合は、受信メールを処理情報送信部２５に出力する。

受信者Ｂ及びＣのチェック部２２は、関係判定部２１から受信メール及び関係なし情報が入力されると、受信メールがメールチェッカ１０によるチェックの対象であるか否かを判定する（ステップＳ１２３、Ｓ１４３）。受信者Ｂ及びＣのチェック部２２は、受信メールにＵＲＬ及び添付ファイルのうち１以上が存在しているので、チェック対象であると判定する（ステップＳ１２３、Ｓ１４３肯定）。なお、図１０では省略したが、チェック部２２は、受信メールがメールチェッカ１０によるチェック対象でない場合は、受信メールを処理情報送信部２５に出力する。受信者Ｂ及びＣのチェック部２２は、受信メールの受信者Ａのメールチェッカ１０から処理情報が送信されて、受信者Ｂ及びＣのメール受信部２０で処理情報を受信するまで待機する（ステップＳ１２４、Ｓ１４４）。

受信者Ａのアラート処理部２３は、チェック部２２から受信メールが入力され、処理情報を取得又は生成する。受信者Ａのアラート処理部２３は、ポリシー設定２９に格納されているホワイトリスト及びポリシー設定を参照する（ステップＳ１０４）。受信者Ａのアラート処理部２３は、送信者Ｘのアドレスがホワイトリストに登録されている、又は、ポリシー設定に適合する場合には（ステップＳ１０４肯定）、受信者Ａに対して警告を発せず、スルー処理としてスルー情報を生成する。スルー処理のイメージは、例えば、図９中の（１）及び（２）に示すようになる。

受信者Ａのアラート処理部２３は、送信者Ｘの送信元アドレスがホワイトリストに登録されていない場合には（ステップＳ１０４否定）、受信者Ａに対して警告を発するアラート処理を行う（ステップＳ１０５）。受信者Ａのアラート処理部２３は、表示部１３に受信メールの少なくとも一部、例えば、本文の冒頭等、並びに、ＵＲＬ及び添付ファイルのうち１以上に関する情報を、ポップアップ画面として表示する。また、受信者Ａのアラート処理部２３は、表示部１３にポップアップ画面内等に、受信メールを安全化するか否かの選択肢を併せて表示する。

受信者Ａのアラート処理部２３は、受信者Ａによって受信メールを安全化するか否かの選択肢が選択されると、操作部１４の操作情報に基づき、処理情報を取得する。処理情報は、例えば、安全化を行う旨の安全化情報、又は、受信メールに対してユーザがそのまま受信する確認を行った旨の確認済情報である。受信者Ａのアラート処理部２３は、取得又は生成した処理情報を、受信メールとともにメール処理部２４に出力する。ここで、受信者Ａのアラート処理部２３が出力した処理情報は、例えば、安全化情報であったとする。

受信者Ａのメール処理部２４は、アラート処理部２３から、受信メール及び処理情報として安全化情報が入力される。受信者Ａのメール処理部２４は、受信した安全化情報に基づいて、受信メールを処理する（ステップＳ１０６）。受信者Ａのメール処理部２４は、安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。

受信者Ａの処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。受信者Ａの処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、受信メールの同報受信者である受信者Ｂ、Ｃ及びＥのうち、端末１にメールチェッカ１０を導入している同報受信者である受信者Ｂ及びＣに対して、処理情報を送信する（ステップＳ１０７）。受信者Ａの処理情報送信部２５は、処理情報の送信が完了すると、受信メールをメーラー４０に出力する（ステップＳ１０８）。

その後、受信者Ｂでの処理が完了し、受信者Ｂの処理情報送信部２５から、受信者Ｂのメールチェッカ１０での処理情報が送信される場合がある。受信者Ａのメール受信部２０は、処理情報を受信すると、信頼度判定部２６に処理情報を出力する。信頼度判定部２６は、入力された処理情報を信頼度情報ＤＢ３０に格納する（ステップＳ１０９）。

続いて、受信者Ａのメールチェッカ１０から処理情報を受信した、受信者Ｂのメールチェッカ１０の動作を説明する。

受信者Ｂのメール受信部２０は、受信者Ａのメールチェッカ１０から送信された処理情報を受信する（ステップＳ１２５）。受信者Ｂのメール受信部２０は、処理情報をチェック部２２及び信頼度判定部２６に出力する。

受信者Ｂのチェック部２２は、メール受信部２０から処理情報が入力されると、受信メールを信頼度判定部２６に出力する。受信者Ｂの信頼度判定部２６は、メール受信部２０から処理情報が入力され、チェック部２２から受信メールが入力される。

受信者Ｂの信頼度判定部２６は、受信メールの同報受信者である受信者Ａについて、履歴ＤＢ２８及び信頼度情報ＤＢ３０を参照する。受信者Ｂの信頼度判定部２６は、履歴ＤＢ２８及び信頼度情報ＤＢ３０から取得した受信者Ａの情報に基づいて、処理情報の信頼度を判定する（ステップＳ１２６）。受信者Ｂの信頼度判定部２６は、受信者Ｂが、過去に送信者Ｘ及び受信者Ａとのメールのやり取りがないので、信頼度なしと判定する（ステップＳ１２６否定）。受信者Ｂの信頼度判定部２６は、受信メール及び処理情報をアラート処理部２３に出力する。なお、受信者Ｂの信頼度判定部２６が信頼度ありと判定した場合は、ここでは説明を省略する。

受信者Ｂのアラート処理部２３は、信頼度判定部２６から受信メール及び処理情報が入力される。受信者Ｂのアラート処理部２３は、受信メール及び処理情報が入力されると、受信者Ｂであるユーザに対して警告を発するアラート処理を行う（ステップＳ１２７）。ここで、アラート処理は、受信者Ａのアラート処理と同様の処理が行われる。受信者Ｂのアラート処理部２３は、アラート処理の結果、安全化情報又は確認済情報を取得する。受信者Ｂのアラート処理部２３は、取得した安全化情報又は確認済情報を処理情報として、受信メールとともにメール処理部２４に出力する。ここで、例えば、受信者Ｂのアラート処理部２３が送信した処理情報は、安全化情報であったとする。

受信者Ｂのメール処理部２４は、アラート処理部２３から、受信メール及び処理情報として安全化情報が入力される。受信者Ｂのメール処理部２４は、受信した安全化情報に基づいて、受信メールを処理する（ステップＳ１２８）。受信者Ｂのメール処理部２４は、安全化情報を処理情報として、処理済みの受信メールとともに処理情報送信部２５に出力する。

受信者Ｂの処理情報送信部２５は、メール処理部２４から受信メール及び処理情報が入力される。受信者Ｂの処理情報送信部２５は、チェッカ導入ＤＢ３１を参照して、受信メールの同報受信者である受信者Ａ、Ｃ及びＥのうち、端末１にメールチェッカ１０を導入している同報受信者である受信者Ａ及びＣに対して、処理情報を送信する（ステップＳ１２９）。受信者Ｂの処理情報送信部２５は、処理情報の送信が完了すると、受信メールをメーラー４０に出力する（ステップＳ１３０）。

続いて、受信者Ａのメールチェッカ１０から処理情報を受信した、受信者Ｃのメールチェッカ１０の動作を説明する。

受信者Ｃのメール受信部２０は、受信者Ａのメールチェッカ１０から送信された処理情報を受信する（ステップＳ１４５）。受信者Ｃのメール受信部２０は、処理情報をチェック部２２及び信頼度判定部２６に出力する。なお、受信者Ｃのメール受信部２０が受信した処理情報は、安全化情報である。

受信者Ｃのチェック部２２は、メール受信部２０から処理情報が入力されると、受信メールを信頼度判定部２６に出力する。受信者Ｃの信頼度判定部２６は、メール受信部２０から処理情報が入力され、チェック部２２から受信メールが入力される。

受信者Ｃの信頼度判定部２６は、受信メールの同報受信者である受信者Ａについて、履歴ＤＢ２８及び信頼度情報ＤＢ３０を参照する。受信者Ｃの信頼度判定部２６は、履歴ＤＢ２８及び信頼度情報ＤＢ３０から取得した受信者Ａの情報に基づいて、処理情報の信頼度を判定する（ステップＳ１４６）。受信者Ｃの信頼度判定部２６は、受信者Ｃが、過去に送信者Ｘとのメールのやり取りはないが、受信者Ａとはメールのやり取りがあり信頼関係があるので、信頼度ありと判定する（ステップＳ１４６肯定）。受信者Ｃの信頼度判定部２６は、受信メール及び処理情報をメール処理部２４に出力する。なお、受信者Ｃの信頼度判定部２６が信頼度なしと判定した場合は、ここでは説明を省略する。

受信者Ｃのメール処理部２４は、信頼度判定部２６から受信メール及び処理情報として安全化情報が入力される。受信者Ｃのメール処理部２４は、入力された安全化情報に基づいて、受信メールを処理する（ステップＳ１４７）。受信者Ｃのメール処理部２４は、処理済みの受信メールを処理情報送信部２５に出力する。

受信者Ｃの処理情報送信部２５は、メール処理部２４から受信メールが入力される。受信者Ｃの処理情報送信部２５は、受信メールをメーラー４０に出力する（ステップＳ１４８）。

その後、受信者Ｂでの処理が完了し、受信者Ｂの処理情報送信部２５から、受信者Ｂのメールチェッカ１０での処理情報が送信される場合がある。受信者Ｃのメール受信部２０は、処理情報を受信すると、信頼度判定部２６に処理情報を出力する。信頼度判定部２６は、入力された処理情報を信頼度情報ＤＢ３０に格納する（ステップＳ１４９）。本実施例のメールチェックシステムの処理によれば、処理情報を複数の端末１のメールチェッカ１０で共有することができる。

次に、本実施例のメールチェックシステムにおける処理情報のやり取りの一例を説明する。図１１は、本実施例のメールチェックシステムの処理情報のやり取りの一例を示す説明図である。

図１１は、例えば、送信元のＸさんが、宛先がＡさん、Ｂさん、Ｃさん及びＤさんであるメールを送信した場合を示す。当該メールの宛先種別は、Ａさん及びＣさんが“Ｔｏ”、Ｂさん及びＤさんが“Ｃｃ”であるとする。また、当該メールは、例えば、本文中にＵＲＬが記載されており、Ａさん、Ｂさん、Ｃさん及びＤさんの端末１に導入されているメールチェッカ１０は、当該メールに対して、基本的にアラートを発報するものとする。

まず、送信元のＸさんからメールが送信される。Ａさん、Ｂさん、Ｃさん及びＤさんの端末１のメールチェッカ１０は、当該メールを受信する。以下、各人の端末１のメールチェッカ１０を単にメールチェッカ１０と称し、当該メールを受信メールと称して説明する。Ａさんのメールチェッカ１０は、Ａさんが端末１のメーラー４０で、受信メールを受信する操作を行うと、受信メールは、チェックポリシーに基づきチェック対象メールであると判定する。

Ａさんのメールチェッカ１０は、アラート処理を行い、例えば、端末１の表示部１３に警告画面をポップアップ表示する。Ａさんは、例えば、警告画面から安全化処理を行う様に操作する。Ａさんのメールチェッカ１０は、受信メールに対して安全化処理を行なって、受信メールをメーラー４０に出力する。また、Ａさんのメールチェッカ１０は、処理情報をメールでＢさん、Ｃさん及びＤさんに送信する。ここで、処理情報を送信する処理情報メールは、例えば、表題（Ｓｕｂｊｅｃｔ）を特殊なものとすることで、通常の受信メールとは区別して処理を可能とする。図１１の例では、処理情報メールの内容として、メッセージＩＤ、表題及び処理結果が記載されている。他にも、処理情報メールとして、メッセージＩＤを表題に入れ、処理結果を本文に記入するようにしてもよい。

Ｂさんのメールチェッカ１０は、Ａさんのメールチェッカ１０と同様の処理を行なって警告画面をポップアップ表示する。このとき、Ｂさんのメールチェッカ１０は、警告画面にＡさんの処理情報を参照可能に表示する。Ｂさんは、Ａさんの処理情報を参照しながら、例えば、警告画面からそのまま受信するために、確認済処理を行う操作をする。Ｂさんのメールチェッカ１０は、受信メールに対して確認済処理を行なって、受信メールをメーラー４０に出力する。また、Ｂさんのメールチェッカ１０は、処理情報をメールでＡさん、Ｃさん及びＤさんに送信する。

Ｃさんのメールチェッカ１０は、Ａさんのメールチェッカ１０と同様の処理を行なって警告画面をポップアップ表示する。このとき、Ｃさんのメールチェッカ１０は、警告画面にＡさん及びＢさんの処理情報を参照可能に表示する。Ｃさんは、Ａさん及びＢさんの処理情報を参照しながら、例えば、警告画面からそのまま受信するために、確認済処理を行う操作をする。Ｃさんのメールチェッカ１０は、受信メールに対して確認済処理を行なって、受信メールをメーラー４０に出力する。また、Ｃさんのメールチェッカ１０は、処理情報をメールでＡさん、Ｂさん及びＤさんに送信する。

Ｄさんのメールチェッカ１０は、Ａさんのメールチェッカ１０と同様の処理を行なって警告画面をポップアップ表示する。このとき、Ｄさんのメールチェッカ１０は、警告画面にＡさん、Ｂさん及びＣさんの処理情報を参照可能に表示する。Ｄさんは、Ａさん、Ｂさん及びＣさんの処理情報を参照しながら、例えば、警告画面からそのまま受信するために、確認済処理を行う操作をする。Ｄさんのメールチェッカ１０は、受信メールに対して確認済処理を行なって、受信メールをメーラー４０に出力する。また、Ｄさんのメールチェッカ１０は、処理情報をメールでＡさん、Ｂさん及びＣさんに送信する。

この様に、本実施例のメールチェックシステムは、先に受信メールを処理した人の処理結果を、処理情報として参照することができるようにしてもよい。すなわち、本実施例のメールチェックシステムは、メールチェッカ１０内の処理に処理情報を用いるだけでなく、各宛先のユーザがどの様に受信メールを処理したかを確認できるため、受信メールに対して、より適切な対応を行うことができる。例えば、他の宛先のユーザのうち、一人でも安全化処理を行なっていたら、安全化処理を行う等とすることができる。また、新規の受信者は、新たな履歴の蓄積も行うことができる。なお、メールチェッカ１０は、アラートの対象となる受信メールは後回しとし、過去の利用状況からスルー処理となる受信メールを先に処理するようにしてもよい。

また、表示する他のユーザの宛先の処理情報は、宛先種別によって変化させてもよい。例えば、宛先種別が“Ｔｏ”である宛先のメールチェッカ１０から送信された処理情報は、受取人と処理内容を表示する。また、宛先種別が“Ｃｃ”である宛先のメールチェッカ１０から送信された処理情報は、処理内容と人数、又は、処理内容の比率のみ表示する。

本実施例のメールチェッカ１０は、第１のアドレスおよび第２のアドレスを宛先に含む受信メールの第１のアドレスと、受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、受信メールに対する処理を実行する。また、メールチェッカ１０は、当該処理に関する情報を第２のアドレスに送信する。また、メールチェッカ１０は、通信履歴が所定の基準を満たさない場合に、第２のアドレスから受信した、受信メールに対して実行された処理に関する情報に基づいて、受信メールに対する処理を実行する。その結果、複数のメールチェッカ１０が、処理に関する情報を互いに送受信することで、受信したメールに対する処理に関する情報を共有することができる。

また、複数のメールチェッカ１０が、処理に関する情報を共有することで、メールチェックシステムを構成できる。更に、複数のメールチェッカ１０が、処理に関する情報を共有することで、あるユーザの宛先のメールチェッカ１０が初めて受信する送信元のメールであっても、初回受信時の過剰アラートを抑制できる。言い換えると、本実施例のメールチェッカ１０は、複数のターゲットに送信されたメールの信頼性をチェックできる。

また、メールチェッカ１０が受信メールに対して行う処理は、第１のアドレスのユーザに対して警告を発するアラート処理、又は、第１のアドレスのユーザに対して警告を発しないスルー処理である。また、アラート処理は、受信メールが確認済であることを示す確認済処理、又は、受信メールを安全化したことを示す安全化処理である。また、処理に関する情報は、確認済処理を行った確認済情報、安全化処理を行った安全化情報、又は、スルー処理を行ったスルー情報である。その結果、メールチェッカ１０は、ユーザに対して適切に警告を発することができる。

また、メールチェッカ１０は、通信履歴が、所定の基準を満たさない場合に、第２のアドレスの信頼度を表す信頼度情報に基づいて、受信した処理に関する情報の信頼度を判定し、信頼度の判定結果に応じた受信メールに対する処理を実行する。その結果、第２のアドレスの信頼度によって、受信メールの処理を行うことができる。

更に、メールチェッカ１０は、アラート処理によって、第１のアドレスのユーザから確認済情報又は安全化情報を取得する。その結果、アラート処理に当該ユーザの意向を反映することができる。

また、メールチェッカ１０は、予め定められたポリシー設定に従ってチェック対象メールであるか否かをチェックし、信頼度情報に基づいて、処理に関する情報の信頼度を判定する。その結果、チェック対象メールに対して、信頼関係にある第２のアドレスの処理に関する情報のみを用いることができる。

更に、メールチェッカ１０は、受信した処理に関する情報が信頼度なしと判定した場合、アラート処理によって、第１のアドレスのユーザから安全化情報又は確認済情報を取得する。その結果、受信した処理に関する情報の信頼度がなくても、アラート処理に第１のアドレスのユーザの意向を反映することができる。

また、メールチェッカ１０は、チェックポリシーとして、メール内のＵＲＬ及び添付ファイルのうち１以上の有無を含む。その結果、ＵＲＬを含まずテキストのみのメールについては第１のアドレスのユーザに警告せず、危険度の高いメールについてのみ第１のアドレスのユーザに警告することができる。

更に、メールチェッカ１０は、信頼度情報として、第２のアドレスとの処理に関する情報の送受信履歴、或いは、第１のアドレスのユーザ及び第２のアドレスのユーザの、所属グループ又は役職に基づく情報を用いる。その結果、信頼度の有無を適切に設定することができる。

また、メールチェッカ１０は、アウトバンドホワイトリストを参照する。その結果、第１のアドレスのユーザからメールを送信し、送信したメールに対する相手からの返信メールについて、警告の発報を抑制することができる。

また、課題として次の点も挙げられる。例えば、特定の組織内で共有サーバを用いてホワイトリストの情報を共有した場合、当該組織内では信頼できる送信者の情報を共有することができる。しかし、例えば、他の組織や外部を含めたグループや委員会等では、共有サーバを用いて信頼できる送信者の情報を共有することは、アクセス制限等により困難であることが多い。更に、共有サーバの機能を各端末に分散することは、端末の増減等により、ホワイトリストの情報共有を、リアルタイムに実現することは容易ではない。

これに対して、本実施例の複数のメールチェッカ１０からなるメールチェックシステムは、共有サーバを用いずに、他のユーザの宛先とホワイトリスト、つまり、安全な送信元の情報を共有することができる。また、本実施例のメールチェックシステムは、共有サーバを用いないことから、例えば、他の組織や外部を含めたグループや委員会等のメンバー間においても、ホワイトリストの情報をリアルタイムに共有することができる。

なお、上記実施例では、端末１の数を３台又は４台で説明したが、これに限定されない。端末１の数は、複数台であれば適宜増減してもよい。

また、上記実施例では、送信元とユーザの宛先との間で、過去にメールのやり取りがあったか否かで、処理情報を提供する側と提供される側とに分けて処理を行ったが、これに限定されない。処理情報を提供する側と提供される側の処理は、他の条件によって、どちらの処理を行うか決定してもよい。例えば、同程度の信頼度のユーザが複数いる場合には、どのユーザのメールチェッカが処理情報を提供してもよく、乱数等によってランダムに決定してもよい。

また、上記実施例では、信頼度の判定を２段階としたが、これに限定されない。信頼度の判定は、信頼度の高いユーザの処理情報を、より信頼度が高い情報として用いて、信頼度の判定を３段階以上としてもよい。

また、上記実施例では、受信メールに対する処理情報を、安全化情報、確認済情報及びスルー情報としたが、これに限定されない。受信メールに対する処理情報は、受信メールを隔離した隔離情報、及び、受信を拒否した受信拒否情報等を用いてもよい。

また、上記実施例では、宛先の端末１のユーザが、他の宛先から多数の処理情報が送信されるまで、受信メールを処理しないこともありえるが、ダミーの処理情報や受信メールの一部の情報を流すことで、受信メールの処理を促してもよい。

また、上記実施例では、処理情報を提供される側で、信頼度を自動的に判定していたが、これに限定されない。例えば、メールチェッカがＬ−ＤＡＰ（Lightweight Directory Access Protocol）等を用いて、ディレクトリサービスにアクセスし、処理情報を提供する他の宛先のユーザのメール又は電話等の問合せ方法を、宛先のユーザに提供するようにしてもよい。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

以上、本実施例を含む実施の形態に関し、更に以下の付記を開示する。

（付記１）コンピュータに、第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行し、当該処理に関する情報を前記第２のアドレスに送信し、
前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行する
各処理を実行させることを特徴とするメールチェックプログラム。

（付記２）前記受信メールに対して行う処理は、前記第１のアドレスのユーザに対して警告を発するアラート処理、又は、前記第１のアドレスのユーザに対して警告を発しないスルー処理であり、前記アラート処理は、前記受信メールが確認済であることを示す確認済処理、又は、前記受信メールを安全化したことを示す安全化処理であり、
前記処理に関する情報は、確認済処理を行った確認済情報、安全化処理を行った安全化情報、又は、スルー処理を行ったスルー情報であることを特徴とする付記１に記載のメールチェックプログラム。

（付記３）前記通信履歴が、前記所定の基準を満たさない場合に、前記第２のアドレスの信頼度を表す信頼度情報に基づいて、受信した前記処理に関する情報の信頼度を判定し、
前記信頼度の判定結果に応じた前記受信メールに対する処理を実行する処理をさらに前記コンピュータに実行させることを特徴とする付記１又は２に記載のメールチェックプログラム。

（付記４）前記信頼度情報は、前記第２のアドレスとの前記処理に関する情報の送受信履歴、或いは、前記第１のアドレスのユーザ及び前記第２のアドレスのユーザの、所属グループ又は役職に基づく情報であることを特徴とする付記３に記載のメールチェックプログラム。

（付記５）第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行するアラート処理部と、
当該処理に関する情報を前記第２のアドレスに送信する送信部と、
前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行するメール処理部と、
を有することを特徴とするメールチェック装置。

（付記６） 複数のメールチェック装置を有するメールチェックシステムであって、
各メールチェック装置は、
第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行するアラート処理部と、
当該処理に関する情報を前記第２のアドレスに送信する送信部と、
前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行するメール処理部と、を有し、
前記処理に関する情報を各メールチェック装置間で共有することを特徴とするメールチェックシステム。

（付記７）コンピュータに、
第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行し、当該処理に関する情報を前記第２のアドレスに送信し、
前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行する
各処理を実行させることを特徴とするメールチェック方法。

１ 端末
１０ メールチェッカ
１１ プロセッサ
１２ メモリ
１３ 表示部
１４ 操作部
１５ 補助記憶装置
１６ ネットワークインタフェース
２０ メール受信部
２１ 関係判定部
２２ チェック部
２３ アラート処理部
２４ メール処理部
２５ 処理情報送信部
２６ 信頼度判定部
２７ 記憶部
２８ 履歴データベース（履歴ＤＢ）
２９ ポリシー設定
３０ 信頼度情報データベース（信頼度情報ＤＢ）
３１ チェッカ導入データベース（チェッカ導入ＤＢ）
４０ メーラー
４１ アウトバンド処理部
４２ アウトバンドホワイトリストデータベース（アウトバンドホワイトリストＤＢ）

Claims (6)

1. コンピュータに、
   第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行し、当該処理に関する情報を前記第２のアドレスに送信し、
   前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行する
   各処理を実行させることを特徴とするメールチェックプログラム。
2. 前記受信メールに対して行う処理は、前記第１のアドレスのユーザに対して警告を発するアラート処理、又は、前記第１のアドレスのユーザに対して警告を発しないスルー処理であり、前記アラート処理は、前記受信メールが確認済であることを示す確認済処理、又は、前記受信メールを安全化したことを示す安全化処理であり、
   前記処理に関する情報は、確認済処理を行った確認済情報、安全化処理を行った安全化情報、又は、スルー処理を行ったスルー情報であることを特徴とする請求項１に記載のメールチェックプログラム。
3. 前記通信履歴が、前記所定の基準を満たさない場合に、前記第２のアドレスの信頼度を表す信頼度情報に基づいて、受信した前記処理に関する情報の信頼度を判定し、
   前記信頼度の判定結果に応じた前記受信メールに対する処理を実行する
   処理をさらに前記コンピュータに実行させることを特徴とする請求項１又は２に記載のメールチェックプログラム。
4. 前記信頼度情報は、前記第２のアドレスとの前記処理に関する情報の送受信履歴、或いは、前記第１のアドレスのユーザ及び前記第２のアドレスのユーザの、所属グループ又は役職に基づく情報であることを特徴とする請求項３に記載のメールチェックプログラム。
5. 第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行するアラート処理部と、
   当該処理に関する情報を前記第２のアドレスに送信する送信部と、
   前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行するメール処理部と、
   を有することを特徴とするメールチェック装置。
6. 複数のメールチェック装置を有するメールチェックシステムであって、
   各メールチェック装置は、
   第１のアドレスおよび第２のアドレスを宛先に含む受信メールの前記第１のアドレスと、前記受信メールの送信元アドレスとの間の通信履歴が所定の基準を満たす場合に、前記受信メールに対する処理を実行するアラート処理部と、
   当該処理に関する情報を前記第２のアドレスに送信する送信部と、
   前記通信履歴が前記所定の基準を満たさない場合に、前記第２のアドレスから受信した、前記受信メールに対して実行された処理に関する情報に基づいて、前記受信メールに対する処理を実行するメール処理部と、を有し、
   前記処理に関する情報を各メールチェック装置間で共有することを特徴とするメールチェックシステム。

Images