ホーム > 特許ランキング > 株式会社ファイブドライブ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-01-11
(45)【発行日】2024-01-19
(54)【発明の名称】ゲートウェイ装置、通信システム、端末装置及びプログラム
(51)【国際特許分類】
H04L 51/214 20220101AFI20240112BHJP
H04L 51/212 20220101ALI20240112BHJP
H04L 51/23 20220101ALI20240112BHJP
【ＦＩ】
H04L51/214
H04L51/212
H04L51/23
【請求項の数】
9
(21)【出願番号】P 2023516460
(86)(22)【出願日】2023-03-09
(86)【国際出願番号】 JP2023009009
【審査請求日】2023-07-21
【早期審査対象出願】
(73)【特許権者】
【識別番号】507177847
【氏名又は名称】株式会社ファイブドライブ
(74)【代理人】
【識別番号】100118289
【弁理士】
【氏名又は名称】関 昌充
(72)【発明者】
【氏名】太田 敏雄
(72)【発明者】
【氏名】藤田 浩和
(72)【発明者】
【氏名】宮本 康広
(72)【発明者】
【氏名】宮本 純子
【審査官】小林 義晴
(56)【参考文献】
【文献】特開２００６－３５０８７０（ＪＰ，Ａ）
【文献】米国特許出願公開第２００８／０１８９７７０（ＵＳ，Ａ１）
【文献】特開２００８－１３９９２６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／０３２４７６７（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ５１／２１４
Ｈ０４Ｌ ５１／２１２
Ｈ０４Ｌ ５１／２３
(57)【特許請求の範囲】
【請求項1】
送信サーバから出口サーバまでの間にメールが転送される回数（経路数）が既知であるドメインのドメイン名と、少なくとも前記送信サーバのホスト名またはＩＰアドレスのいずれかと、少なくとも前記出口サーバのホスト名またはＩＰアドレスのいずれかと、前記メールが転送される経路数を対応付けて保持する経路保持手段と、受信したメールのヘッダから、当該メールの送信元のドメイン名と、送信サーバのホスト名またはＩＰアドレスと、出口サーバのホスト名またはＩＰアドレスと、送信サーバから出口サーバ当該装置までのメールの経路数を抽出し、前記抽出した送信サーバのホスト名またはＩＰアドレスと、前記抽出した出口サーバのホスト名またはＩＰアドレスと、前記抽出した送信サーバから出口サーバまでのメールの経路数が、前記経路保持手段に保持されている情報と一致する場合に、当該メールを配信する判定手段と、
を備えることを特徴とするゲートウェイ装置。
【請求項2】
ドメイン名毎のメールの送受信履歴に応じた送信元ドメインの信用度を保持する信用度保持手段を備え、前記判定手段は、
受信したメールのヘッダから、当該メールの送信元メールアドレスのドメイン名を抽出する抽出手段と、
該抽出手段が抽出したドメイン名に対応する送信元ドメインの信用度を示す情報を付加する付加手段と、
を備えることを特徴とする請求項１記載のゲートウェイ装置。
【請求項3】
受信したメールのヘッダ中の当該メール送信元のメールアドレス宛にメールの送信を確認する確認メールを送信する確認手段を備え、前記判定手段は、
前記確認メールに対する応答があったときに、前記受信したメールを配信する、
ことを特徴とする請求項１または請求項２記載のゲートウェイ装置。
【請求項4】
前記判定手段は、隔離するメールの送信サーバの少なくともホスト名またはＩＰアドレスのいずれかを保持するブラックリスト保持手段と、
他の組織の判定手段のブラックリストを登録する登録手段と、
を備えることを特徴とする請求項１または請求項２に記載のゲートウェイ装置。
【請求項5】
前記判定手段は、
隔離するメールの送信サーバの少なくともホスト名またはＩＰアドレスのいずれかを保持するブラックリスト保持手段と、
他の組織の判定手段のブラックリストを登録する登録手段と、
を備えることを特徴とする請求項３記載のゲートウェイ装置。
【請求項6】
請求項１または請求項２に記載のゲートウェイ装置と、メールを受信する受信サーバと、
を備えることを特徴とする通信システム。
【請求項7】
請求項３記載のゲートウェイ装置と、
メールを受信する受信サーバと、
を備えることを特徴とする通信システム。
【請求項8】
請求項４記載のゲートウェイ装置と、
メールを受信する受信サーバと、
を備えることを特徴とする通信システム。
【請求項9】
コンピュータに、受信したメールのヘッダから、当該メールの送信元のドメイン名と、送信サーバのホスト名またはＩＰアドレスと、出口サーバのホスト名またはＩＰアドレスと、送信サーバから出口サーバ当該装置までのメールの経路数を抽出させ、
前記抽出した送信サーバのホスト名またはＩＰアドレスと、前記抽出した出口サーバのホスト名またはＩＰアドレスと、前記抽出した送信サーバから出口サーバまでのメールの経路数が、送信サーバから出口サーバまでの間にメールが転送される回数（経路数）が既知であるドメインのドメイン名と、少なくとも前記送信サーバのホスト名またはＩＰアドレスのいずれかと、少なくとも前記出口サーバのホスト名またはＩＰアドレスのいずれかと、前記メールが転送される経路数を対応付けて保持する経路保持手段に保持されている情報と一致する場合に、当該メールを配信させる、
ことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、受信メールの正当性の判定において正確性を向上させるゲートウェイ装置、通信システム、端末装置及びプログラムに関する。
【背景技術】
【0002】
近年、標的企業の幹部などに偽装したメール（なりすましメール）等の不正なメールにより、受信者に不利益を与える、なりすましメールによる被害が増加している。特に、社内に在籍する者を送信者のように偽装された場合には、甚大な被害が発生する場合もあり得る。
不正なメールを検出する技術としてＳＰＦ認証やＤＫＩＭ、ＤＭＡＲＣなどの送信元ドメイン認証技術が知られている。これらの送信元ドメイン認証技術では送信元のドメインとＩＰアドレスの登録が必要であることから、認証可能なドメインは登録済みのドメインに限られるという問題がある。また、送信元ドメインやＩＰアドレスが変更された場合、登録情報の変更が適時に行われない場合、認証されない問題などがある。特許文献１では複数のメールサーバからホワイトリストを収集し、統合したデータをメールサーバに配信することで最新の適切な送信元情報による送信元メールサーバの確認を行う方法が採られている。
不正なメールを検出する技術としてＳＰＦ認証やＤＫＩＭ、ＤＭＡＲＣなどの送信元ドメイン認証技術が知られている。これらの送信元ドメイン認証技術では送信元のドメインとＩＰアドレスの登録が必要であることから、認証可能なドメインは登録済みのドメインに限られるという問題がある。また、送信元ドメインやＩＰアドレスが変更された場合、登録情報の変更が適時に行われない場合、認証されない問題などがある。特許文献１では複数のメールサーバからホワイトリストを収集し、統合したデータをメールサーバに配信することで最新の適切な送信元情報による送信元メールサーバの確認を行う方法が採られている。
【0003】
メールの正当性を確認することが困難となる根本的な原因は、各組織の正規なメールサーバの情報が公表されていないことに起因する。ＳＰＦ認証は、各組織で正規なメールサーバを登録することでこの問題を解決しようとしたものだが、メールサーバが変更された際に登録変更が適切に行われない場合があることや、攻撃者が類似ドメインを登録しＳＰＦ認証を設定した場合、受信者からは正規のメールのように見えることがあるなどの問題がある。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０２０－２７５１０号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、メールのヘッダ中の送信元メールアドレスは、送信元（攻撃者側）で偽装することも可能であり、また、送信サーバのＩＰアドレスについても、送信元でヘッダ中に追加することも可能である。
さらに、送信サーバのＩＰアドレスは、システムの再起動や構成変更により変わることもあり得る。
このため、単に、送信元のメールアドレス、送信サーバのＩＰアドレス等により、メールの正当性を判定するだけでは不十分である。
本発明は、受信メールの正当性の判定において正確性を向上させることを目的とする。
さらに、送信サーバのＩＰアドレスは、システムの再起動や構成変更により変わることもあり得る。
このため、単に、送信元のメールアドレス、送信サーバのＩＰアドレス等により、メールの正当性を判定するだけでは不十分である。
本発明は、受信メールの正当性の判定において正確性を向上させることを目的とする。
【課題を解決するための手段】
【0006】
上述の課題を解決するため、本発明に係るゲートウェイ装置は、送信サーバから出口サーバまでの間にメールが転送される回数（経路数）が既知であるドメインのドメイン名と、少なくとも前記送信サーバのホスト名またはＩＰアドレスのいずれかと、少なくとも前記出口サーバのホスト名またはＩＰアドレスのいずれかと、前記メールが転送される経路数を対応付けて保持する経路保持手段と、受信したメールのヘッダから、当該メールの送信元のドメイン名と、送信サーバのホスト名またはＩＰアドレスと 、出口サーバのホスト名またはＩＰアドレスと、送信サーバから出口サーバ当該装置までのメールの経路数を抽出し、 前記抽出した送信サーバのホスト名またはＩＰアドレスと、前記抽出した出口サーバのホスト名またはＩＰアドレスと、前記抽出した送信サーバから出口サーバまでのメールの経路数が、前記経路保持手段に保持されている情報と一致する場合に、当該メールを配信する判定手段と、を備えている。
【0007】
また、本発明に係る他のゲートウェイ装置は、ドメイン毎のメールの送受信履歴に応じた送信元ドメインの信用度を保持する信用度保持手段と、受信したメールのヘッダから、当該メールの送信元メールアドレスのドメイン名を抽出する抽出手段と、該抽出手段が抽出したドメイン名に対応する送信元ドメインの信用度を示す情報を付加したメールを配信する配信手段と、を備えている。
【0008】
また、本発明に係る他のゲートウェイ装置は、受信したメールのヘッダから、当該メールの送信元メールアドレスを抽出する抽出手段と、該抽出手段が抽出したメールアドレス宛にメールの送信を確認する確認メールを送信する確認手段と、該確認メールに対する応答があったときに、前記受信したメールを配信する判定手段と、を備えている。
【発明の効果】
【0009】
本発明のゲートウェイ装置では、判定手段が、受信したメールのヘッダから、当該メールの送信元のドメイン名と、送信サーバのホスト名またはＩＰアドレスと 、出口サーバのホスト名またはＩＰアドレスと、送信サーバから出口サーバ当該装置までのメールの経路数を抽出し、 前記抽出した送信サーバのホスト名またはＩＰアドレスと、前記抽出した出口サーバのホスト名またはＩＰアドレスと、前記抽出した送信サーバから出口サーバまでのメールの経路数が、経路保持手段に保持されている情報と一致する場合に、当該メールを配信することにより、受信メールの正当性の判定において正確性を向上させることができる。
【図面の簡単な説明】
【0010】
【図1】実施形態１の通信システムの構成例を示すブロック図。
【図2】判定サーバの構成例を示すブロック図。
【図3】公開メールアドレステーブルの例を示す図。
【図4】信用度評価基準テーブルの例を示す図。
【図5】社内メール情報テーブルの例を示す図。
【図6】組織基本情報テーブルの例を示す図。
【図7】メールサーバ情報テーブルの例を示す図。
【図8】ブラックリストテーブルの例を示す図。
【図9】メールの受信時の判定サーバの処理の例を示すフローチャート。
【図10】メールのヘッダの例を示す図。
【図11】メールのヘッダの例を示す図。
【図12】判定部が付加するヘッダの例を示す図。
【図13】判定部が付加するヘッダの例を示す図。
【図14】ユーザ端末の表示部に表示される画面の例を示す図。
【図15】管理端末で表示される管理画面の例を示す図。
【発明を実施するための形態】
【0011】
以下、本発明の実施形態について説明するが、本発明はこれに限定されるものではなく、本発明の技術的思想の範囲内で適宜変更することができる。
（実施形態１）
＜通信システム構成＞
図１は、実施形態１の通信システムの構成例を示すブロック図である。
この通信システムは、例えばインターネット等のネットワーク１を介して通信可能な判定サーバ１０と、メールの受信を行う受信サーバ２０と、メールの送信を行う送信サーバ３０とを備えている。判定サーバ１０は、受信サーバ２０に対して、受信メールの判定を行うゲートウェイ装置として動作する。また、この通信システムは、Ｗｅｂサービスを提供するＷｅｂサーバ４０と、通信システムの管理者が用いる管理者端末５０と、ユーザがメールの送受信に用いるユーザ端末６０とを備えている。なお、判定サーバ１０～ユーザ端末６０は、例えば会社内あるいは部門毎等の管理対象の組織毎に設けられている。また、ユーザ端末６０は、複数のユーザが使用するため、複数備えている。また、この図１では、受信サーバ２０、送信サーバ３０、Ｗｅｂサーバ４０を判定サーバ１０とは別に設けた場合について示しているが、これらのうちのいくつかを判定サーバ１０内に設けてもよい。また、この通信システムでは、例えば複数の組織毎に設けられた判定サーバ１０に蓄積されたデータを集約する情報集約サーバ９０を備えている。
（実施形態１）
＜通信システム構成＞
図１は、実施形態１の通信システムの構成例を示すブロック図である。
この通信システムは、例えばインターネット等のネットワーク１を介して通信可能な判定サーバ１０と、メールの受信を行う受信サーバ２０と、メールの送信を行う送信サーバ３０とを備えている。判定サーバ１０は、受信サーバ２０に対して、受信メールの判定を行うゲートウェイ装置として動作する。また、この通信システムは、Ｗｅｂサービスを提供するＷｅｂサーバ４０と、通信システムの管理者が用いる管理者端末５０と、ユーザがメールの送受信に用いるユーザ端末６０とを備えている。なお、判定サーバ１０～ユーザ端末６０は、例えば会社内あるいは部門毎等の管理対象の組織毎に設けられている。また、ユーザ端末６０は、複数のユーザが使用するため、複数備えている。また、この図１では、受信サーバ２０、送信サーバ３０、Ｗｅｂサーバ４０を判定サーバ１０とは別に設けた場合について示しているが、これらのうちのいくつかを判定サーバ１０内に設けてもよい。また、この通信システムでは、例えば複数の組織毎に設けられた判定サーバ１０に蓄積されたデータを集約する情報集約サーバ９０を備えている。
【0012】
また、この通信システムは、受信サーバ２０等にメールを送信する送信端末７０、７４と、送信サーバ７１、７５と、を備えている。なお、送信端末７０、送信サーバ７１は、正規のメールの送信に用いられる端末を想定しており、送信端末７４、送信サーバ７５は、不正なメールの送信に用いられる端末を想定している。
ネットワーク１の構成等にもよるが、遠隔地の送信サーバから送信された電子メールの転送は、複数の送信サーバ（ＳＭＴＰサーバ）を経由して行われることが一般的であり、以下の説明では、最終的にメールを外部のネットワーク１に送出する送信サーバを便宜的に出口サーバという。
ネットワーク１の構成等にもよるが、遠隔地の送信サーバから送信された電子メールの転送は、複数の送信サーバ（ＳＭＴＰサーバ）を経由して行われることが一般的であり、以下の説明では、最終的にメールを外部のネットワーク１に送出する送信サーバを便宜的に出口サーバという。
【0013】
送信サーバ７１からのメールは、出口サーバ７２を介して、外部のネットワーク１に送信される。なお、組織内のネットワーク構成、ホスティングサービスの利用等によっては、送信サーバ７１から出口サーバ７２までの間に他の送信サーバが介在することもある。この場合は、各送信サーバ間でメールが転送される時に、メールにＲｅｃｉｅｉｖｅｄヘッダが追加される。
また、送信サーバ７５からのメールは、出口サーバ７６を介して、外部のネットワーク１に送信される。なお、送信端末７４と送信サーバ７５が１つの装置で構成されていたり、送信端末７４と送信サーバ７５と出口サーバ７６が同一の装置で構成されていたりすることもあり得る。
なお、送信端末７０、送信サーバ７１は、組織外に設けた場合について想定しているが、組織内の宛先に対するメールの送信の場合には、組織内に設けられている場合も想定される。また、この通信システムは、ＩＰアドレスとドメイン名の対応関係を管理するＤＮＳサーバ８１を備えている。
また、送信サーバ７５からのメールは、出口サーバ７６を介して、外部のネットワーク１に送信される。なお、送信端末７４と送信サーバ７５が１つの装置で構成されていたり、送信端末７４と送信サーバ７５と出口サーバ７６が同一の装置で構成されていたりすることもあり得る。
なお、送信端末７０、送信サーバ７１は、組織外に設けた場合について想定しているが、組織内の宛先に対するメールの送信の場合には、組織内に設けられている場合も想定される。また、この通信システムは、ＩＰアドレスとドメイン名の対応関係を管理するＤＮＳサーバ８１を備えている。
【0014】
また、ユーザ端末６０は、例えばパーソナルコンピュータ、携帯情報端末等の情報処理装置で構成されており、メールクライアント６１と、表示部６２とを備えている。メールクライアント６１は、後述のように、判定サーバ１０でメールのヘッダに付加される送信元の信頼度を示すメール信用度スコアに応じた表示を表示部６２に表示する表示プラグイン６１１を備えている。
【0015】
図２は、判定サーバ１０の構成例を示すブロック図である。
この判定サーバ１０は、受信サーバ２０の受信履歴と送信サーバ３０の送信履歴等を解析する履歴解析部１１と、ネットワーク１を介して受信したメールの判定を行う判定部１２と、各種データを保持するデータ保持部１３とを備えている。この判定サーバ１０は、ネットワーク１経由で受信したメールの正当性を判断し、所定の条件を満たしている場合に受信サーバ２０に供給するゲートウェイ装置（あるいはＰｒｏｘｙサーバ）としても動作する。
この判定サーバ１０は、受信サーバ２０の受信履歴と送信サーバ３０の送信履歴等を解析する履歴解析部１１と、ネットワーク１を介して受信したメールの判定を行う判定部１２と、各種データを保持するデータ保持部１３とを備えている。この判定サーバ１０は、ネットワーク１経由で受信したメールの正当性を判断し、所定の条件を満たしている場合に受信サーバ２０に供給するゲートウェイ装置（あるいはＰｒｏｘｙサーバ）としても動作する。
【0016】
データ保持部１３には、例えば図３から図８に示すように、判定部１２における判定に用いる各種テーブルが保持されている。また、データ保持部１３の隔離領域または保留領域には、判定部１２による判定の結果、「隔離」あるいは「保留」されたメールが格納される。
図３は、データ保持部１３に格納されている公開メールアドレステーブル１０１の例を示す図である。
この公開メールアドレステーブル１０１では、管理対象の組織について、外部に公開されている「メールアドレス（ドメインを除いた部分）」毎に、「宛先アドレス信用度スコア」が対応付けて格納されている。具体的には、図３に示すように、当該組織のウェブサイト等で公開されているメールアドレスについては、宛先アドレス信用度スコアを低くする。なお、限定的に公開されているメールアドレス（例えば図３の場合では「ｓａｌｅｓ」）については、別途スコア（例えば「０．５」等）を設定してもよい。なお、公開メールアドレステーブル１０１に含まれていないメールアドレスについては、例えば宛先アドレス信用度スコアを「１」とする。また公開メールアドレステーブル１０１の情報は、例えば当該通信システムの運用開始時等に、初期設定として設定するが、例えば管理者端末５０等から適宜設定を変更するようにしてもよい。
図３は、データ保持部１３に格納されている公開メールアドレステーブル１０１の例を示す図である。
この公開メールアドレステーブル１０１では、管理対象の組織について、外部に公開されている「メールアドレス（ドメインを除いた部分）」毎に、「宛先アドレス信用度スコア」が対応付けて格納されている。具体的には、図３に示すように、当該組織のウェブサイト等で公開されているメールアドレスについては、宛先アドレス信用度スコアを低くする。なお、限定的に公開されているメールアドレス（例えば図３の場合では「ｓａｌｅｓ」）については、別途スコア（例えば「０．５」等）を設定してもよい。なお、公開メールアドレステーブル１０１に含まれていないメールアドレスについては、例えば宛先アドレス信用度スコアを「１」とする。また公開メールアドレステーブル１０１の情報は、例えば当該通信システムの運用開始時等に、初期設定として設定するが、例えば管理者端末５０等から適宜設定を変更するようにしてもよい。
【0017】
図４は、データ保持部１３に格納されている信用度評価基準テーブル１０２の例を示す図である。
この信用度評価基準テーブル１０２は、「信用度ランク」に対して、対応する後述の「メール信用度スコア」と、対応する信用度ランクを規定するテーブルである。この信用度評価基準テーブルでは、所定の閾値で区切られた「メール信用度スコア」毎に対応する「信用度ランク」を規定している。なお、信用度ランクに応じた動作の詳細については、後述する。また、閾値（図４の場合では「７０」、「３０」）の値については適宜設定することができる。
この信用度評価基準テーブル１０２は、「信用度ランク」に対して、対応する後述の「メール信用度スコア」と、対応する信用度ランクを規定するテーブルである。この信用度評価基準テーブルでは、所定の閾値で区切られた「メール信用度スコア」毎に対応する「信用度ランク」を規定している。なお、信用度ランクに応じた動作の詳細については、後述する。また、閾値（図４の場合では「７０」、「３０」）の値については適宜設定することができる。
【0018】
＜ホワイトリスト＞
図５から図７は、データ保持部１３に格納されているメールの送信元の信用度を判定するための「ホワイトリスト」に含まれる各テーブルの例を示す図である。
図５は、ホワイトリストの社内メール情報テーブル１０３の例を示す図である。
この社内メール情報テーブル１０３には、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名またはＩＰアドレスと出口サーバ７２までの間の経路が明確に把握できている既知の組織に対して、例えば「組織名」、「ドメイン」、「送信元ホスト名（送信サーバ７１のホスト名）」、「送信元ＩＰアドレス（送信サーバ７１のＩＰアドレス）」、「出口サーバ名（出口サーバ７２のホスト名）」「出口サーバＩＰアドレス（出口サーバ７２のＩＰアドレス）」、送信サーバから出口サーバまでの経路数を示す「経路」が対応付けて格納されている。なお、送信サーバ７１と出口サーバ７２のホスト名とＩＰアドレスがＤＮＳサーバ８１で一対一に対応付けられている場合には、いずれか一方を登録しておくようにしてもよいが、送信サーバ７１に関しては、ＩＰアドレスが変わることもあるため、両方を登録しておくことが望ましい。
図５から図７は、データ保持部１３に格納されているメールの送信元の信用度を判定するための「ホワイトリスト」に含まれる各テーブルの例を示す図である。
図５は、ホワイトリストの社内メール情報テーブル１０３の例を示す図である。
この社内メール情報テーブル１０３には、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名またはＩＰアドレスと出口サーバ７２までの間の経路が明確に把握できている既知の組織に対して、例えば「組織名」、「ドメイン」、「送信元ホスト名（送信サーバ７１のホスト名）」、「送信元ＩＰアドレス（送信サーバ７１のＩＰアドレス）」、「出口サーバ名（出口サーバ７２のホスト名）」「出口サーバＩＰアドレス（出口サーバ７２のＩＰアドレス）」、送信サーバから出口サーバまでの経路数を示す「経路」が対応付けて格納されている。なお、送信サーバ７１と出口サーバ７２のホスト名とＩＰアドレスがＤＮＳサーバ８１で一対一に対応付けられている場合には、いずれか一方を登録しておくようにしてもよいが、送信サーバ７１に関しては、ＩＰアドレスが変わることもあるため、両方を登録しておくことが望ましい。
【0019】
メールのヘッダには、メールを転送する各送信サーバが、メールを受信した送信元のサーバのホスト名とＩＰアドレスと、当該送信サーバのホスト名とＩＰアドレス等を含むＲｅｃｅｉｖｅｄヘッダを随時追加する。上述の社内メール情報テーブル１０３中の「経路」は、後述のように、メールのヘッダに含まれる送信サーバ７１が追加したＲｅｃｅｉｖｅｄヘッダと、出口サーバ７２が追加したＲｅｃｅｉｖｅｄヘッダの間の経路数を示す数である。例えば図５の１行目の株式会社Ｘの場合、正規のメールのヘッダでは、例えば図１０に示すように、経路数は３となる。
なお、同一組織に複数のドメインが存在する場合には、図５のように、ドメイン毎に各情報が対応付けられて格納される。図５の場合では、送信元の送信サーバ７１が複数であるが、出口サーバ７２は１つである場合について示している。また、関連会社、取引先等については、各々の関連会社、取引先等について同様の情報が格納される。
これらの情報は、当該通信システムの運用開始時等に、初期設定として設定するが、例えば管理者端末５０等から適宜設定を変更するようにしてもよい。
会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名またはＩＰアドレスと、出口サーバ７２までの間の経路が明確に把握できている既知の組織に対しては、社内メール情報テーブル１０３に登録しておき、当該テーブルに基づいて、受信したメールの正当性を判断することにより、正当性の判定の確実性を向上させることができる。
なお、同一組織に複数のドメインが存在する場合には、図５のように、ドメイン毎に各情報が対応付けられて格納される。図５の場合では、送信元の送信サーバ７１が複数であるが、出口サーバ７２は１つである場合について示している。また、関連会社、取引先等については、各々の関連会社、取引先等について同様の情報が格納される。
これらの情報は、当該通信システムの運用開始時等に、初期設定として設定するが、例えば管理者端末５０等から適宜設定を変更するようにしてもよい。
会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名またはＩＰアドレスと、出口サーバ７２までの間の経路が明確に把握できている既知の組織に対しては、社内メール情報テーブル１０３に登録しておき、当該テーブルに基づいて、受信したメールの正当性を判断することにより、正当性の判定の確実性を向上させることができる。
【0020】
図６は、ホワイトリストの組織基本情報テーブル１０４の例を示す図である。
この組織基本情報テーブル１０４には、既知の通信相手（組織）に対して、「組織名」、「ドメイン」、「住所」、「電話番号」、メールの「送信数」、メールの「受信数」、一連のメールの送受信（スレッド）の平均値「スレッド平均」、当該組織との「取引期間」と、後述の「組織信用度スコア」が対応付けて格納されている。なお、「送信数」は、送信サーバ３０が当該組織に送信したメールの総数であり、「受信数」は、当該組織から受信サーバ２０が受信したメールの総数であり、「取引期間」は、受信サーバ２０が受信した最初のメールからの日数である。
この組織基本情報テーブル１０４には、既知の通信相手（組織）に対して、「組織名」、「ドメイン」、「住所」、「電話番号」、メールの「送信数」、メールの「受信数」、一連のメールの送受信（スレッド）の平均値「スレッド平均」、当該組織との「取引期間」と、後述の「組織信用度スコア」が対応付けて格納されている。なお、「送信数」は、送信サーバ３０が当該組織に送信したメールの総数であり、「受信数」は、当該組織から受信サーバ２０が受信したメールの総数であり、「取引期間」は、受信サーバ２０が受信した最初のメールからの日数である。
【0021】
組織基本情報テーブル１０４中の「組織名」、「ドメイン」、「住所」、「電話番号」は、当該通信システムの運用開始時等に、初期設定として設定するが、例えば管理者端末５０等から適宜設定を変更するようにしてもよい。また、「住所」、「電話番号」は必ずしも設定しなくてもよい。
組織基本情報テーブル１０４中の「送信数」、「受信数」、「スレッド平均」、「取引期間」は、履歴解析部１１が、受信サーバ２０の受信履歴と送信サーバ３０の送信履歴から算出する。
また、「組織信用度スコア」は、後述のように、履歴解析部１１が、送信数、受信数、スレッド平均、取引期間を用いて算出する。送信数、受信数、スレッド平均、取引期間は日々変化するので、日次でアップデートする。また、これらのアップデートに基づいて組織信用度スコアも、履歴解析部１１が日次で更新する。
組織基本情報テーブル１０４中の「送信数」、「受信数」、「スレッド平均」、「取引期間」は、履歴解析部１１が、受信サーバ２０の受信履歴と送信サーバ３０の送信履歴から算出する。
また、「組織信用度スコア」は、後述のように、履歴解析部１１が、送信数、受信数、スレッド平均、取引期間を用いて算出する。送信数、受信数、スレッド平均、取引期間は日々変化するので、日次でアップデートする。また、これらのアップデートに基づいて組織信用度スコアも、履歴解析部１１が日次で更新する。
【0022】
組織信用度スコアは、例えば、以下の計算式によって求めるが、計算式はメールの送受信の実態、求められる判定の正確性等に応じて適宜変更してもよい。
具体的には、例えば送信数：５００、受信数：５００、スレッド平均：１０、取引期間：３６５日を満たした状態を組織信用度スコア１００とする場合、以下のような計算式となる。
組織信用度スコア ＝ ＭＩＮ（２５×（送信数／５００），２５）＋ＭＩＮ（２５×（受信数／５００），２５）＋ＭＩＮ（２５×（スレッド平均／１０），２５）＋ＭＩＮ（２５×（取引期間／３６５），２５）
ここで、ＭＩＮ（Ａ，Ｂ）はＡ≧ＢのときＢとなり、Ａ＜ＢのときＡとなる関数である。
例えば、図６の組織信用度基本情報テーブル１０４の１行目に登録されている株式会社Ａの場合、送信数２０１、受信数２５４、スレッド平均２３．４、取引期間１０２３日であるため、上の式に当てはめると、
組織信用度スコア ＝ ＭＩＮ（２５×（２０１／５００），２５）＋ＭＩＮ（２５×（２５４／５００），２５）＋ＭＩＮ（２５×（２３．４／１０），２５）＋ＭＩＮ（２５×（１０２３／３６５），２５） ＝ １０．０５＋１２．７＋２５＋２５ ＝ ７２．７５
となる。
具体的には、例えば送信数：５００、受信数：５００、スレッド平均：１０、取引期間：３６５日を満たした状態を組織信用度スコア１００とする場合、以下のような計算式となる。
組織信用度スコア ＝ ＭＩＮ（２５×（送信数／５００），２５）＋ＭＩＮ（２５×（受信数／５００），２５）＋ＭＩＮ（２５×（スレッド平均／１０），２５）＋ＭＩＮ（２５×（取引期間／３６５），２５）
ここで、ＭＩＮ（Ａ，Ｂ）はＡ≧ＢのときＢとなり、Ａ＜ＢのときＡとなる関数である。
例えば、図６の組織信用度基本情報テーブル１０４の１行目に登録されている株式会社Ａの場合、送信数２０１、受信数２５４、スレッド平均２３．４、取引期間１０２３日であるため、上の式に当てはめると、
組織信用度スコア ＝ ＭＩＮ（２５×（２０１／５００），２５）＋ＭＩＮ（２５×（２５４／５００），２５）＋ＭＩＮ（２５×（２３．４／１０），２５）＋ＭＩＮ（２５×（１０２３／３６５），２５） ＝ １０．０５＋１２．７＋２５＋２５ ＝ ７２．７５
となる。
【0023】
＜メール信用度スコアの計算＞
また、判定部１２は、ネットワーク１経由で受信した個々のメールについて、メール信用度スコアを算出する。このメール信用度スコアの計算には、例えば以下の計算式を用いることができるが、計算式はメールの送受信の実態、求められる判定の正確性等に応じて適宜変更してもよい。
メール信用度スコア ＝ 宛先メールアドレス信用度スコア × 組織信用度スコア
すなわち、本実施形態では、受信したメールの送信先メールアドレスに対応する図３中の「宛先メールアドレス信用度スコア」とメールの送信元の組織に対応する図６中の「組織信用度スコア」の積により、個々のメールの信用度を求めている。
また、判定部１２は、ネットワーク１経由で受信した個々のメールについて、メール信用度スコアを算出する。このメール信用度スコアの計算には、例えば以下の計算式を用いることができるが、計算式はメールの送受信の実態、求められる判定の正確性等に応じて適宜変更してもよい。
メール信用度スコア ＝ 宛先メールアドレス信用度スコア × 組織信用度スコア
すなわち、本実施形態では、受信したメールの送信先メールアドレスに対応する図３中の「宛先メールアドレス信用度スコア」とメールの送信元の組織に対応する図６中の「組織信用度スコア」の積により、個々のメールの信用度を求めている。
【0024】
図７は、ホワイトリストのメールサーバ情報テーブル１０５の例を示す図である。
このメールサーバ情報テーブル１０５には、既知の通信相手（組織）に対して、「組織名」、送信サーバ７１のＩＰアドレスと送信サーバ７１のホスト名が対応付けて格納されている。
なお、メールサーバ情報テーブル１０５に登録するホスト名は、履歴解析部１１が、受信サーバ２０で受信したメールのＲｅｃｅｉｖｅｄヘッダから抽出する、履歴解析部１１は、抽出したすべてのデータをメールサーバ情報テーブル１０５に登録する。
このメールサーバ情報テーブル１０５には、既知の通信相手（組織）に対して、「組織名」、送信サーバ７１のＩＰアドレスと送信サーバ７１のホスト名が対応付けて格納されている。
なお、メールサーバ情報テーブル１０５に登録するホスト名は、履歴解析部１１が、受信サーバ２０で受信したメールのＲｅｃｅｉｖｅｄヘッダから抽出する、履歴解析部１１は、抽出したすべてのデータをメールサーバ情報テーブル１０５に登録する。
【0025】
＜ブラックリスト＞
図８は、データ保持部１３に保持されているブラックリストテーブル１０６の例を示す図である。
このブラックリストテーブル１０６には、なりすましメールを送信した送信サーバの「ＩＰアドレス」と「ホスト名」が登録される。
なお、当該通信システムの運用開始時等には、初期設定として空のブラックリストテーブル１０６を作成する。当該通信システムの運用中に、判定部１２が、受信したメールが不正であると判定した場合は、当該メールの送信サーバのＩＰアドレスとホスト名をブラックリストに登録する。
図８は、データ保持部１３に保持されているブラックリストテーブル１０６の例を示す図である。
このブラックリストテーブル１０６には、なりすましメールを送信した送信サーバの「ＩＰアドレス」と「ホスト名」が登録される。
なお、当該通信システムの運用開始時等には、初期設定として空のブラックリストテーブル１０６を作成する。当該通信システムの運用中に、判定部１２が、受信したメールが不正であると判定した場合は、当該メールの送信サーバのＩＰアドレスとホスト名をブラックリストに登録する。
【0026】
＜動作概要＞
本実施形態の通信システムでは、従来のように、単に、送信元のメールアドレス、送信サーバのＩＰアドレス等に応じてメール配信の可否を判定するのではなく、大きく分けて以下の３つの処理を組み合わせて、受信メールの正当性の判定における正確性を向上させている。
なお、受信メールの正当性判断の難しさは正規の送信元のメールサーバのホスト名、ＩＰアドレス等が公表されておらず、正規なメールサーバから送信されたメールであるか不明な点にある。
１．メール信用度スコアの付加
２．組織内（経路が明確に把握できている既知の組織）の送信者からのメールである場合の経路の判定
３．メールの送信元に対する確認
なお、本実施形態では、以上の３つの処理を全て実装した例について説明するが、いずれか１つの処理を実装したり、任意の２つの処理を組み合わせて実装したりすることも可能である。少なくともいずれか１つの処理を実装することにより、受信メールの正当性の判定において正確性を向上させることができる。
本実施形態の通信システムでは、従来のように、単に、送信元のメールアドレス、送信サーバのＩＰアドレス等に応じてメール配信の可否を判定するのではなく、大きく分けて以下の３つの処理を組み合わせて、受信メールの正当性の判定における正確性を向上させている。
なお、受信メールの正当性判断の難しさは正規の送信元のメールサーバのホスト名、ＩＰアドレス等が公表されておらず、正規なメールサーバから送信されたメールであるか不明な点にある。
１．メール信用度スコアの付加
２．組織内（経路が明確に把握できている既知の組織）の送信者からのメールである場合の経路の判定
３．メールの送信元に対する確認
なお、本実施形態では、以上の３つの処理を全て実装した例について説明するが、いずれか１つの処理を実装したり、任意の２つの処理を組み合わせて実装したりすることも可能である。少なくともいずれか１つの処理を実装することにより、受信メールの正当性の判定において正確性を向上させることができる。
【0027】
＜メール受信時の動作＞
図９は、メール受信時の判定サーバの処理の例を示すフローチャートである。
ネットワーク１を介してメールを受信すると、判定サーバ１０の判定部１２は、図９の処理を開始する。
判定部１２は、Ｓ１１において、メールを受信し、続くＳ１２において、受信したメールのヘッダから送信元のメールサーバのＩＰアドレス、送信元のメールサーバのホスト名、送信者のメールアドレスを抽出する。
図９は、メール受信時の判定サーバの処理の例を示すフローチャートである。
ネットワーク１を介してメールを受信すると、判定サーバ１０の判定部１２は、図９の処理を開始する。
判定部１２は、Ｓ１１において、メールを受信し、続くＳ１２において、受信したメールのヘッダから送信元のメールサーバのＩＰアドレス、送信元のメールサーバのホスト名、送信者のメールアドレスを抽出する。
【0028】
Ｓ１３において、判定部１２は、送信者のメールアドレスのドメインが社内メール情報テーブル１０３に登録されているドメインと一致するか否かを判定し、一致する場合には、Ｓ１４において、受信したメールのヘッダ中の送信元ホスト名、送信元ＩＰアドレス、出口サーバ名、出口サーバＩＰアドレス、経路が社内メール情報テーブル１０３に登録されている各情報と一致するか否かを判定する。
一致する場合には、判定部１２は、Ｓ１５において、メール信用度スコアを満点（例えば１００）とし、例えば図１２（Ａ）に示すように、受信したメールのヘッダに当該スコアと当該スコアに対応する信用度ランクを表示するメッセージを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）を付加して受信サーバ２０に配信し、図９の処理を終了する。
なお、「Ｘ－Ｈａｎｔｅｉ」ヘッダに追加する情報は、この例に限らず、例えば信用度スコアのみとしたり、信用度ランクを示す情報のみとしたりしてもよい。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じて、例えば図１３に示すように、表示部６２に「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じた表示６２１を表示させる。
一致する場合には、判定部１２は、Ｓ１５において、メール信用度スコアを満点（例えば１００）とし、例えば図１２（Ａ）に示すように、受信したメールのヘッダに当該スコアと当該スコアに対応する信用度ランクを表示するメッセージを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）を付加して受信サーバ２０に配信し、図９の処理を終了する。
なお、「Ｘ－Ｈａｎｔｅｉ」ヘッダに追加する情報は、この例に限らず、例えば信用度スコアのみとしたり、信用度ランクを示す情報のみとしたりしてもよい。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じて、例えば図１３に示すように、表示部６２に「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じた表示６２１を表示させる。
【0029】
一方、Ｓ１４において、受信したメールのヘッダ中の送信元ホスト名、送信元ＩＰアドレス、出口サーバ名、出口サーバＩＰアドレス、経路のいずれかが社内メール情報テーブル１０３に登録されている各情報と異なる場合には、組織内の発信者を偽装しているメールであるため、判定部１２は、Ｓ１６において、当該メールをデータ保持部１３の隔離領域に格納し、ブラックリストに登録がなければ登録し、図９の処理を終了する。
例えば、メールのヘッダ中の送信元メールアドレス（エンベロープＦｒｏｍのメールアドレス）が組織内のものであっても、送信元ホスト名、送信元ＩＰアドレスが異なっている場合には、正規の送信サーバ７１で送信されたものではなく、送信者を偽装した送信サーバ７５からの偽装メールである。
例えば、メールのヘッダ中の送信元メールアドレス（エンベロープＦｒｏｍのメールアドレス）が組織内のものであっても、送信元ホスト名、送信元ＩＰアドレスが異なっている場合には、正規の送信サーバ７１で送信されたものではなく、送信者を偽装した送信サーバ７５からの偽装メールである。
【0030】
図１０は、正規の組織内の送信者が送信した場合に、判定サーバに到達するまでの転送経路の各メールサーバによって受信側のメールに付加される「Ｒｅｃｉｅｉｖｅｄ」ヘッダ２０１の例を示す図である。
図１１は、偽装メールの送信元で、偽装のため正規のメールと同様の「Ｒｅｃｉｅｉｖｅｄ」ヘッダを追加したメールを送信した場合に、判定サーバに到達するまでの転送経路の各メールサーバによって受信側のメールに付加される「Ｒｅｃｉｅｉｖｅｄ」ヘッダの例を示す図である。
この例では、偽装メールの送信元（例えば端末装置７４）で、偽装のため正規のメールと同様の「Ｒｅｃｉｅｉｖｅｄ」ヘッダ２０２を追加しているが、実際の送信元である送信端末７４から出口サーバ７６までの転送履歴２０３が追加されている。
このようなメールを受信した場合、単純にヘッダ中の送信元のホスト名、ＩＰアドレスを確認しただけでは、正規のメールと区別がつかない場合がある。
しかしながら、偽装した「Ｒｅｃｉｅｉｖｅｄ」ヘッダ２０２を追加した場合には、実際の送信元である送信端末７４から出口サーバ７６までの転送履歴２０３が追加されて、実際の出口サーバ７６までの経路数が増えているため、本実施形態のように、経路数を社内メール情報テーブル１０３に登録されている経路（経路数）と比較することにより、不正なメールと判定することができ、受信メールの正当性の判定において正確性を向上させることができる。なお、図１１の場合では、判定部１２は、最後に出口サーバで追加された「Ｒｅｃｉｅｉｖｅｄ」ヘッダと、最初の送信サーバで追加された（と偽装されている）「Ｒｅｃｉｅｉｖｅｄ」ヘッダとの間の経路数で判断する。
図１１は、偽装メールの送信元で、偽装のため正規のメールと同様の「Ｒｅｃｉｅｉｖｅｄ」ヘッダを追加したメールを送信した場合に、判定サーバに到達するまでの転送経路の各メールサーバによって受信側のメールに付加される「Ｒｅｃｉｅｉｖｅｄ」ヘッダの例を示す図である。
この例では、偽装メールの送信元（例えば端末装置７４）で、偽装のため正規のメールと同様の「Ｒｅｃｉｅｉｖｅｄ」ヘッダ２０２を追加しているが、実際の送信元である送信端末７４から出口サーバ７６までの転送履歴２０３が追加されている。
このようなメールを受信した場合、単純にヘッダ中の送信元のホスト名、ＩＰアドレスを確認しただけでは、正規のメールと区別がつかない場合がある。
しかしながら、偽装した「Ｒｅｃｉｅｉｖｅｄ」ヘッダ２０２を追加した場合には、実際の送信元である送信端末７４から出口サーバ７６までの転送履歴２０３が追加されて、実際の出口サーバ７６までの経路数が増えているため、本実施形態のように、経路数を社内メール情報テーブル１０３に登録されている経路（経路数）と比較することにより、不正なメールと判定することができ、受信メールの正当性の判定において正確性を向上させることができる。なお、図１１の場合では、判定部１２は、最後に出口サーバで追加された「Ｒｅｃｉｅｉｖｅｄ」ヘッダと、最初の送信サーバで追加された（と偽装されている）「Ｒｅｃｉｅｉｖｅｄ」ヘッダとの間の経路数で判断する。
【0031】
Ｓ１３において、送信者のメールアドレスのドメインが社内メール情報テーブル１０３に登録されているドメインと一致しない場合には、判定部１２は、Ｓ１７において、受信したメールの送信者のメールアドレスのホスト名またはＩＰアドレスがブラックリストテーブル１０６に登録されているか否かを判定する。
登録されている場合には、判定部１２は、Ｓ１８において、当該メールをデータ保持部１３の隔離領域に格納し、ブラックリストに登録がなければ登録し図９の処理を終了する。
登録されている場合には、判定部１２は、Ｓ１８において、当該メールをデータ保持部１３の隔離領域に格納し、ブラックリストに登録がなければ登録し図９の処理を終了する。
【0032】
送信者のメールアドレスのホスト名またはＩＰアドレスがブラックリストテーブル１０６に登録されていない場合には、判定部１２は、Ｓ１９において、送信者のメールアドレスのドメインが組織基本情報テーブル１０４に登録されているか否かを判定する。登録されている場合には、判定部１２は、Ｓ２０において、送信元のメールサーバのＩＰアドレスがメールサーバ情報テーブル１０５に登録されているＩＰアドレスと一致するか否かを判定する。
一致している場合には、判定部１２は、Ｓ２１において、例えば図１２（Ｂ）及び同図（Ｃ）に示すように、メール信用度スコアを組織基本情報テーブル１０４に登録されている組織信用度スコアとし、受信したメールのヘッダに当該スコアを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）等を付加して受信サーバ２０に転送し、図９の処理を終了する。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダのスコアに応じて、例えば図１４に示すように、表示部６２に「Ｘ－Ｈａｎｔｅｉ」ヘッダのスコアに応じた表示６２２、あるいは表示６２３を表示させる。
一致している場合には、判定部１２は、Ｓ２１において、例えば図１２（Ｂ）及び同図（Ｃ）に示すように、メール信用度スコアを組織基本情報テーブル１０４に登録されている組織信用度スコアとし、受信したメールのヘッダに当該スコアを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）等を付加して受信サーバ２０に転送し、図９の処理を終了する。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダのスコアに応じて、例えば図１４に示すように、表示部６２に「Ｘ－Ｈａｎｔｅｉ」ヘッダのスコアに応じた表示６２２、あるいは表示６２３を表示させる。
【0033】
Ｓ１９において、送信者のメールアドレスのドメインがホワイトリストの組織基本情報テーブル１０４に登録されていない場合は、送信元の組織からのメールが初めてである等の状態のため、判定部１２は、Ｓ２２において、当該メールをデータ保持部１３の保留領域に格納し、図９の処理を終了する。なお、後述のように、データ保持部１３の保留領域に格納されたメールは、管理者端末５０からの操作により、保留状態を解除された場合には、受信サーバ２０に転送され、ユーザ端末６０から閲覧可能になる。この際、判定部１２は、メール信用度スコアを初めてのメールであることを示す「－１」とし、例えば図１３に示すように、メールのヘッダに当該スコアを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）を付加する。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じて、例えば図１４に示すように、表示部６２に表示６２４を表示させる。
このような「Ｘ－Ｈａｎｔｅｉ」ヘッダを含むメールを受信サーバ２０から受信したメールクライアント６１の表示プラグイン６１１は、「Ｘ－Ｈａｎｔｅｉ」ヘッダに応じて、例えば図１４に示すように、表示部６２に表示６２４を表示させる。
【0034】
Ｓ２０において、送信者のメールアドレスのドメインがホワイトリストの組織基本情報テーブル１０４に登録されているが、送信元のメールサーバのＩＰアドレスがメールサーバ情報テーブル１０５に登録されているＩＰアドレスと一致しない場合には、判定部１２は、Ｓ２３において、送信サーバ３０に指示してメールの送信者のメールアドレス宛ての確認メールを送信させる。
この確認メールには、例えば受信したメールの引用部分とＷｅｂサーバ４０の確認用のアドレスに対するリンク情報等を含める。なお、Ｗｅｂサーバ４０の確認用のアドレスに対するリンク情報ではなく、相手側に確認メールに対する返信を要求するメッセージとしてもよい。
Ｓ２３が実行されるのは、ホワイトリストに登録されている組織を送信元とするメールだが、送信サーバのＩＰアドレスがメールサーバ情報テーブル１０５に登録されているＩＰアドレスとは異なっている状況であり、なりすましメールであるのか、送信元のシステム構成が変わっている等の状況か判らない状況である。このため、判定部１２は、メールの送信元になっているメールアドレス宛に確認のメールを送信する。
この確認メールには、例えば受信したメールの引用部分とＷｅｂサーバ４０の確認用のアドレスに対するリンク情報等を含める。なお、Ｗｅｂサーバ４０の確認用のアドレスに対するリンク情報ではなく、相手側に確認メールに対する返信を要求するメッセージとしてもよい。
Ｓ２３が実行されるのは、ホワイトリストに登録されている組織を送信元とするメールだが、送信サーバのＩＰアドレスがメールサーバ情報テーブル１０５に登録されているＩＰアドレスとは異なっている状況であり、なりすましメールであるのか、送信元のシステム構成が変わっている等の状況か判らない状況である。このため、判定部１２は、メールの送信元になっているメールアドレス宛に確認のメールを送信する。
【0035】
Ｓ２４において、判定部１２は、Ｓ２３で送信した確認メールに対して、相手側がリンク情報に応じてＷｅｂサーバ４０にアクセスし、メールの送信を確認したか否かを判定する。Ｗｅｂサーバ４０からの通知等により、相手側がメールの送信を確認したことを確認すると、判定部１２は、Ｓ２５において、当該受信したメールのヘッダにスコアを示す情報（例えば「Ｘ－Ｈａｎｔｅｉ」ヘッダ）等を付加して受信サーバ２０に転送し、当該メールの送信元のＩＰアドレスとホスト名をメールサーバ情報テーブル１０５に変更登録し、図９の処理を終了する。
【0036】
所定の期限内に相手側がメールの送信を確認したことを確認できない場合には、判定部１２は、Ｓ２６において、当該受信したメールを、データ保持部１３の隔離領域に格納し、当該メールで送信元とされている組織名に対応させて送信元のＩＰアドレス、ホスト名をブラックリストテーブル１０６に登録し、図９の処理を終了する。
【0037】
＜管理者端末５０の動作＞
管理者端末５０では、上述の各種テーブルの保守管理等の他に、上述のＳ２２においてデータ保持部１３に格納されたメールの確認と状態の管理を行うことができるようになっている。
具体的には、管理者端末５０のＷｅｂブラウザを用いて、Ｗｅｂサーバ４０経由で判定サーバ１０によりデータ保持部１３の隔離領域と保留領域に格納されたメールの管理をするための画面にアクセスすることができる。
判定サーバ１０は、Ｗｅｂサーバ４０経由で管理者端末５０からのリクエストに応じて、管理画面を表示させるための、ＨＴＭＬデータを生成し、Ｗｅｂサーバ４０経由で管理者端末５０に供給する。管理者端末５０は、供給されたＨＴＭＬデータに応じて、例えば図１５に示す管理画面５５を表示させる。
この管理画面５５には、データ保持部１３の隔離領域と保留領域に格納されたメール毎に、各々送信元メールアドレス表示領域５５１ａ、件名表示領域５５１ｂ、スコア表示領域５５１ｃ、配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを有する表示５５１の一覧と、選択されたメールの本文が表示されるメール本文表示領域５５２が表示される。管理者端末５０の操作者は、信頼度スコアや送信元メールアドレス、メール本文から総合的に判断してメールを配信するか削除するかを選択し、対応する配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを指示する。
これにより、管理者端末５０の操作者が保留領域に格納されたメールの内容を確認し、問題がなければ状態を、例えば「配信可能」な状態に変更する。この状態の変化に応じて、判定サーバ１０は、当該メールを受信サーバ２０に配信する。管理者端末５０の操作者は隔離領域に格納されたメールについては、メールの内容を確認し削除することができる他、配信指示ボタンを押下することで特定のアドレスに転送することができる。
なお、上述の説明では、隔離または保留するメールをデータ保持部１３の隔離領域または保留領域に保存するようにしていたが、隔離フラグまたは保留フラグ等の情報を対応付けたメールをデータ保持部１３に保存しておき、各フラグ等の情報により隔離または保留したメールの判別を行ってもよい。
管理者端末５０では、上述の各種テーブルの保守管理等の他に、上述のＳ２２においてデータ保持部１３に格納されたメールの確認と状態の管理を行うことができるようになっている。
具体的には、管理者端末５０のＷｅｂブラウザを用いて、Ｗｅｂサーバ４０経由で判定サーバ１０によりデータ保持部１３の隔離領域と保留領域に格納されたメールの管理をするための画面にアクセスすることができる。
判定サーバ１０は、Ｗｅｂサーバ４０経由で管理者端末５０からのリクエストに応じて、管理画面を表示させるための、ＨＴＭＬデータを生成し、Ｗｅｂサーバ４０経由で管理者端末５０に供給する。管理者端末５０は、供給されたＨＴＭＬデータに応じて、例えば図１５に示す管理画面５５を表示させる。
この管理画面５５には、データ保持部１３の隔離領域と保留領域に格納されたメール毎に、各々送信元メールアドレス表示領域５５１ａ、件名表示領域５５１ｂ、スコア表示領域５５１ｃ、配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを有する表示５５１の一覧と、選択されたメールの本文が表示されるメール本文表示領域５５２が表示される。管理者端末５０の操作者は、信頼度スコアや送信元メールアドレス、メール本文から総合的に判断してメールを配信するか削除するかを選択し、対応する配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを指示する。
これにより、管理者端末５０の操作者が保留領域に格納されたメールの内容を確認し、問題がなければ状態を、例えば「配信可能」な状態に変更する。この状態の変化に応じて、判定サーバ１０は、当該メールを受信サーバ２０に配信する。管理者端末５０の操作者は隔離領域に格納されたメールについては、メールの内容を確認し削除することができる他、配信指示ボタンを押下することで特定のアドレスに転送することができる。
なお、上述の説明では、隔離または保留するメールをデータ保持部１３の隔離領域または保留領域に保存するようにしていたが、隔離フラグまたは保留フラグ等の情報を対応付けたメールをデータ保持部１３に保存しておき、各フラグ等の情報により隔離または保留したメールの判別を行ってもよい。
【0038】
以上説明したように、本実施形態では、不正なメールと判定したメールについては、受信サーバ２０に転送せずに隔離し、不正なメールか否かまで判定をつけられないメールについてはメールの信用度を示す情報を付加して受信サーバ２０に転送することにより、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。これに加えて、疑わしいメールには確認メールを送信することによってさらに正確性を向上させることができる。
なお、例えば全ての受信メールに対して確認メールを送信するようにしてもよい。これにより、受信メールの正当性の判定において正確性を向上させることができる。
また、例えば受信サーバ２０に転送するメールに対して上述のメールの信用度を示す情報を付加するだけでも、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。
また、本実施形態では、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名及びＩＰアドレスと、出口サーバ７２までの間の経路が正確に把握できている既知の組織が送信元のメールである場合の経路判定を行うことによって、受信メールの正当性の判定において正確性を向上させることができる。
なお、例えば全ての受信メールに対して確認メールを送信するようにしてもよい。これにより、受信メールの正当性の判定において正確性を向上させることができる。
また、例えば受信サーバ２０に転送するメールに対して上述のメールの信用度を示す情報を付加するだけでも、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。
また、本実施形態では、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名及びＩＰアドレスと、出口サーバ７２までの間の経路が正確に把握できている既知の組織が送信元のメールである場合の経路判定を行うことによって、受信メールの正当性の判定において正確性を向上させることができる。
【0039】
なお、判定部１２は、図８のブラックリストテーブル１０６に記載した情報を、情報集約サーバ９０に送信する。判定サーバ１０は、組織毎に設けられているが、情報集約サーバ９０に集約されたブラックリストの情報を、要望・許諾条件等に応じて他の組織の判定サーバ１０に提供するようにしてもよい。この場合、判定サーバ１０には、提供されたブラックリストを登録する機能を設ける。他の組織のブラックリストテーブルを利用して、ブラックリストテーブル１０６の登録・管理等を行うことにより、ブラックリストテーブル１０６の精緻化が図れるため、作業負担を低減させることができる。
【符号の説明】
【0040】
１…ネットワーク、１０…判定サーバ、１１…履歴解析部、１２…判定部、１３…データ保持部、２０…受信サーバ、３０…送信サーバ、４０…Ｗｅｂサーバ、５０…管理者端末、６０…ユーザ端末、６１、メールクライアント、６１１…表示プラグイン、６２…表示部、７０、７４…送信端末、７１、７５…外部の送信サーバ、７２、７６…出口サーバ、８１…ＤＮＳサーバ、９０…情報集約サーバ
【要約】
ゲートウェイ装置は、受信したメールのヘッダから、当該メールの送信元のドメイン名と、送信サーバのホスト名またはＩＰアドレスと 、出口サーバのホスト名またはＩＰアドレスと、送信サーバから出口サーバ当該装置までのメールの経路数を抽出し、 前記抽出した送信サーバのホスト名またはＩＰアドレスと、前記抽出した出口サーバのホスト名またはＩＰアドレスと、前記抽出した送信サーバから出口サーバまでのメールの経路数が、経路保持手段に保持されている情報と一致する場合に、当該メールを配信する判定手段と、を備える。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】