ホーム > 特許ランキング > 株式会社ファイブドライブ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-07-12
(45)【発行日】2024-07-23
(54)【発明の名称】ゲートウェイ装置、通信システム及びプログラム
(51)【国際特許分類】
H04L 51/212 20220101AFI20240716BHJP
G06F 21/55 20130101ALI20240716BHJP
【ＦＩ】
H04L51/212
G06F21/55 320
【請求項の数】
8
(21)【出願番号】P 2023567871
(86)(22)【出願日】2023-07-26
(86)【国際出願番号】 JP2023027424
【審査請求日】2023-11-13
(31)【優先権主張番号】PCT/JP2023/009009
(32)【優先日】2023-03-09
(33)【優先権主張国・地域又は機関】JP
【早期審査対象出願】
(73)【特許権者】
【識別番号】507177847
【氏名又は名称】株式会社ファイブドライブ
(74)【代理人】
【識別番号】100118289
【弁理士】
【氏名又は名称】関 昌充
(72)【発明者】
【氏名】太田 敏雄
(72)【発明者】
【氏名】中村 太朗
(72)【発明者】
【氏名】藤田 浩和
(72)【発明者】
【氏名】宮本 康広
(72)【発明者】
【氏名】宮本 純子
【審査官】小林 義晴
(56)【参考文献】
【文献】特開２００８－１３９９２６（ＪＰ，Ａ）
【文献】特開２０１３－１７１４３７（ＪＰ，Ａ）
【文献】特開２００６－３５０８７０（ＪＰ，Ａ）
【文献】米国特許出願公開第２００８／０１８９７７０（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ５１／２１２
Ｇ０６Ｆ ２１／５５
(57)【特許請求の範囲】
【請求項1】
送信元のドメイン毎のメールの送受信履歴に応じて送信元ドメインの信用度を評価するドメイン評価手段と、前記ドメイン評価手段による送信元ドメインの信用度に応じた送信元ドメインの信用度データを保持するドメイン信用度保持手段と、
組織内の宛先メールアドレスの公開レベルに応じた宛先アドレスの信用度データを保持する宛先信用度保持手段と、
受信したメールのヘッダから、当該メールの送信元のドメイン名と、前記組織内の宛先メールアドレスを抽出する抽出手段と、
該抽出手段が抽出したドメイン名に対応する前記ドメイン信用度保持手段に保持されている送信元ドメインの信用度データと、前記抽出手段が抽出した前記組織内の宛先メールアドレスに対応する前記宛先アドレスの信用度データとに応じて、前記受信したメールの受信メール信用度データを求める算出手段とを備え、
前記ドメイン評価手段は、
送信数、受信数、スレッド平均、メールのやり取りをしている期間を示す取引期間のうちいずれか２つ以上を用いて送信元ドメインの信用度を評価する、
ことを特徴とするゲートウェイ装置。
【請求項2】
前記宛先信用度保持手段は、前記組織内の宛先メールアドレスが、公開アドレス、限定的公開アドレス、非公開アドレスのいずれであるかに応じた前記信用度データを保持する
ことを特徴とする請求項１記載のゲートウェイ装置。
【請求項3】
前記抽出手段は、受信したメールのヘッダから、当該メールの送信元メールアドレスのドメイン名と送信元メールサーバのＩＰアドレスを抽出し、信頼できる送信元のドメイン名と送信元メールサーバのＩＰアドレスとを保持する保持手段と、
該抽出手段が抽出した当該メールの送信元メールアドレスのドメイン名が前記保持手段に登録されており、当該メールの送信元メールサーバのＩＰアドレスが、前記保持手段に保持されている当該メールの送信元メールアドレスのドメイン名に対応するＩＰアドレスと一致しない場合に、当該メールの送信元メールアドレス宛にメールの送信を確認する確認メールを送信する確認手段と、
該確認メールに対する応答があったときに、前記受信したメールを配信する配信手段と、
を備えることを特徴とする請求項１記載のゲートウェイ装置。
【請求項4】
前記抽出手段は、受信したメールのヘッダから、当該メールの送信元メールアドレスのドメイン名とＲｅｃｅｉｖｅｄヘッダに記載されている送信元サーバのドメイン名を抽出し、正規ドメインのドメイン名を保持する正規ドメイン名保持手段と、
前記抽出手段が抽出した送信元メールアドレスのドメイン名が前記正規ドメイン名保持手段に登録されており、前記抽出したＲｅｃｅｉｖｅｄヘッダに記載されている送信元サーバのドメイン名と一致しない場合に、当該受信したメールの送信元メールアドレス宛にメールの送信を確認する確認メールを送信する確認手段と、
該確認メールに対する応答があったときに、前記受信したメールを配信する配信手段と、
を備えることを特徴とする請求項１記載のゲートウェイ装置。
【請求項5】
正規ドメインのドメイン名を保持する正規ドメイン名保持手段を備え、前記抽出手段は、受信したメールのヘッダから、当該メールの送信元メールアドレスのドメイン名とＲｅｃｅｉｖｅｄヘッダに記載されている送信元サーバのドメイン名を抽出し、
前記確認手段は、前記抽出手段が抽出した送信元メールアドレスのドメイン名が前記正規ドメイン名保持手段に登録されており、前記抽出したＲｅｃｅｉｖｅｄヘッダに記載されている送信元サーバのドメイン名と一致しない場合に、当該受信したメールの送信元メールアドレス宛にメールの送信を確認する確認メールを送信し、
前記配信手段は、該確認メールに対する応答があったときに、前記受信したメールを配信する、
ことを特徴とする請求項３記載のゲートウェイ装置。
【請求項6】
前記算出手段が求めた前記受信したメールの受信メール信用度データを付加したメールを配信する配信手段、を備えることを特徴とする請求項１記載のゲートウェイ装置。
【請求項7】
請求項１から請求項６のいずれか１項に記載のゲートウェイ装置と、メールを受信する受信サーバと、
を備えることを特徴とする通信システム。
【請求項8】
コンピュータに、メールの送信数、受信数、スレッド平均、メールのやり取りをしている期間を示す取引期間のうちいずれか２つ以上を用いて送信元のドメイン毎の送信元ドメインの信用度を評価させ、
受信したメールのヘッダから、当該メールの送信元のドメイン名と、組織内の宛先メールアドレスを抽出させ、
該抽出した宛先メールアドレスに対応する宛先メールアドレスの公開レベルに応じた宛先アドレスの信用度データと、前記抽出した前記送信元のドメイン名に対応する前記送信元ドメインの信用度とに応じて、前記受信したメールの受信メール信用度データを求めさせる、
ことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【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】管理端末で表示される管理画面の例を示す図。
【図16】正規ドメインリストの例を示す図。
【発明を実施するための形態】
【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】
（変形例）
なお、送信元の組織（ドメイン）からのメールが初めてである場合であっても、一部の偽装メールについては、確認メールを送信することでメールの偽装を見破ることが可能となる。
攻撃者からのなりすましメールについて分類すると２パターンの偽装方法が存在する。
（１）Ｆｒｏｍドメイン名が正規ドメイン名と完全一致の偽装メール
（２）Ｆｒｏｍドメイン名を正規ドメイン名に似せた偽装メール
・（１）の偽装メールの場合：
メールヘッダのＦｒｏｍドメイン名が正規のドメイン名と同一であり、この場合、メールに返信すると宛先が正規ドメイン名のため、攻撃者には返信メールが届かず、正規の組織に届くことになる。このため、ＵＲＬをクリックしただけで端末がマルウェアに感染する攻撃など、一発勝負型の攻撃に利用される。
なお、表面上の見た目は正規ドメイン名と同一のため、攻撃対象者に見破られる可能性は低い。
・（２）の偽装メールの場合：
メールヘッダのＦｒｏｍドメイン名が、正規のドメイン名に似せたメールであり、この場合、メールに返信すると宛先が正規ドメイン名と異なるため、正規の組織には届かず攻撃者に返信メールが届き、メールのやり取りをして被害者を信用させるなど時間をかけた攻撃が可能となる。しかしながら、やり取りしているメールのドメイン名が似ているだけで正規ドメイン名と異なっているため、攻撃対象者に見破られる可能性は高い。
なお、送信元の組織（ドメイン）からのメールが初めてである場合であっても、一部の偽装メールについては、確認メールを送信することでメールの偽装を見破ることが可能となる。
攻撃者からのなりすましメールについて分類すると２パターンの偽装方法が存在する。
（１）Ｆｒｏｍドメイン名が正規ドメイン名と完全一致の偽装メール
（２）Ｆｒｏｍドメイン名を正規ドメイン名に似せた偽装メール
・（１）の偽装メールの場合：
メールヘッダのＦｒｏｍドメイン名が正規のドメイン名と同一であり、この場合、メールに返信すると宛先が正規ドメイン名のため、攻撃者には返信メールが届かず、正規の組織に届くことになる。このため、ＵＲＬをクリックしただけで端末がマルウェアに感染する攻撃など、一発勝負型の攻撃に利用される。
なお、表面上の見た目は正規ドメイン名と同一のため、攻撃対象者に見破られる可能性は低い。
・（２）の偽装メールの場合：
メールヘッダのＦｒｏｍドメイン名が、正規のドメイン名に似せたメールであり、この場合、メールに返信すると宛先が正規ドメイン名と異なるため、正規の組織には届かず攻撃者に返信メールが届き、メールのやり取りをして被害者を信用させるなど時間をかけた攻撃が可能となる。しかしながら、やり取りしているメールのドメイン名が似ているだけで正規ドメイン名と異なっているため、攻撃対象者に見破られる可能性は高い。
【0041】
なお、上述の（２）の場合の場合には、確認メールを送信することは、攻撃者の術中に嵌まることを意味し、いかなる返信メールも返してはならない。
ここで、（１）の場合の偽装メールの場合、Ｒｅｃｅｉｖｅｄヘッダに着目してみると、Ｆｒｏｍのドメイン名とＲｅｃｅｉｖｅｄヘッダのホスト名のドメイン名が一致する場合は、メール自体の真偽については正規か否かの判別は不明であるが、Ｆｒｏｍのドメイン名とＲｅｃｅｉｖｅｄヘッダのホスト名のドメイン名が一致しない場合は、Ｆｒｏｍのドメイン名宛に確認メールを送信することでメールの真偽を見破ることができる。
すなわち「上記（１）のＦｒｏｍドメイン名が正規ドメイン名と完全一致の偽装メール」をはじめて受信したケース（ホワイトリスト登録されていない正規ドメイン名を騙ったなりすましメールを受信したケース）では、正規ドメインを騙っている偽装メールのため、確認メールは騙られている正規の相手先に届くこととなり偽装を見破ることができる。
ここで、（１）の場合の偽装メールの場合、Ｒｅｃｅｉｖｅｄヘッダに着目してみると、Ｆｒｏｍのドメイン名とＲｅｃｅｉｖｅｄヘッダのホスト名のドメイン名が一致する場合は、メール自体の真偽については正規か否かの判別は不明であるが、Ｆｒｏｍのドメイン名とＲｅｃｅｉｖｅｄヘッダのホスト名のドメイン名が一致しない場合は、Ｆｒｏｍのドメイン名宛に確認メールを送信することでメールの真偽を見破ることができる。
すなわち「上記（１）のＦｒｏｍドメイン名が正規ドメイン名と完全一致の偽装メール」をはじめて受信したケース（ホワイトリスト登録されていない正規ドメイン名を騙ったなりすましメールを受信したケース）では、正規ドメインを騙っている偽装メールのため、確認メールは騙られている正規の相手先に届くこととなり偽装を見破ることができる。
【0042】
図９の処理では、Ｓ１９において、送信者のメールアドレスのドメインがホワイトリストの組織基本情報テーブル１０４に登録されていない場合は、過去からの送受信メール履歴データからメール信用度の評価を行った信用度データの付加がなく、送信元の組織からのメールが初めてである等の状態のため、判定部１２は、Ｓ２２において、当該メールをデータ保持部１３の保留領域に格納し処理を終了する動作となっている。
これに対し、Ｓ１９において送信者のメールアドレスのドメインがホワイトリストの組織基本情報テーブル１０４に登録されていない場合に以下の処理を行ってもよい。
（Ａ１）Ｆｒｏｍのドメイン名が正規ドメインリスト（図１６）に登録されているドメインのいずれかと一致するかを判別する。
（Ａ２）（Ａ１）の判別の結果、Ｆｒｏｍのドメイン名が正規ドメインリストに登録されている場合で、ＦｒｏｍのドメインとＲｅｃｅｉｖｅｄヘッダのドメインが一致する場合はＳ２２において当該メールをデータ保持部１３の保留領域に格納する。
（Ａ３）Ｆｒｏｍのドメイン名が正規ドメインリストに登録されている場合で、ＦｒｏｍのドメインとＲｅｃｅｉｖｅｄヘッダのドメインが一致しない場合は、Ｆｒｏｍのメールアドレス宛に確認メールを送信する。このとき、確認メールに対する応答が得られた場合は、Ｆｒｏｍのドメインから送信された正しいメールであるとしてＳ２２において当該メールをデータ保持部１３の保留領域に格納する。確認メールに対する応答が得られなかった場合は、Ｆｒｏｍのドメインからのメールを偽装したメールとして、ＲｅｃｅｉｖｅｄのＩＰアドレスとホスト名をブラックリストに登録しメールを隔離するＳ２６の処理を実行する。
（Ａ４）（Ａ１）の判別の結果、Ｆｒｏｍのドメイン名が正規ドメインリストに登録されていない場合は、Ｓ２２において当該メールをデータ保持部１３の保留領域に格納する。
なお、正規ドメインリストは、例えば図１６に示すように、政府ドメインリストや上場企業の公開情報等から予め作成したリスト１０７を示す。
これに対し、Ｓ１９において送信者のメールアドレスのドメインがホワイトリストの組織基本情報テーブル１０４に登録されていない場合に以下の処理を行ってもよい。
（Ａ１）Ｆｒｏｍのドメイン名が正規ドメインリスト（図１６）に登録されているドメインのいずれかと一致するかを判別する。
（Ａ２）（Ａ１）の判別の結果、Ｆｒｏｍのドメイン名が正規ドメインリストに登録されている場合で、ＦｒｏｍのドメインとＲｅｃｅｉｖｅｄヘッダのドメインが一致する場合はＳ２２において当該メールをデータ保持部１３の保留領域に格納する。
（Ａ３）Ｆｒｏｍのドメイン名が正規ドメインリストに登録されている場合で、ＦｒｏｍのドメインとＲｅｃｅｉｖｅｄヘッダのドメインが一致しない場合は、Ｆｒｏｍのメールアドレス宛に確認メールを送信する。このとき、確認メールに対する応答が得られた場合は、Ｆｒｏｍのドメインから送信された正しいメールであるとしてＳ２２において当該メールをデータ保持部１３の保留領域に格納する。確認メールに対する応答が得られなかった場合は、Ｆｒｏｍのドメインからのメールを偽装したメールとして、ＲｅｃｅｉｖｅｄのＩＰアドレスとホスト名をブラックリストに登録しメールを隔離するＳ２６の処理を実行する。
（Ａ４）（Ａ１）の判別の結果、Ｆｒｏｍのドメイン名が正規ドメインリストに登録されていない場合は、Ｓ２２において当該メールをデータ保持部１３の保留領域に格納する。
なお、正規ドメインリストは、例えば図１６に示すように、政府ドメインリストや上場企業の公開情報等から予め作成したリスト１０７を示す。
【0043】
＜管理者端末５０の動作＞
管理者端末５０では、上述の各種テーブルの保守管理等の他に、上述のＳ２２においてデータ保持部１３に格納されたメールの確認と状態の管理を行うことができるようになっている。
具体的には、管理者端末５０のＷｅｂブラウザを用いて、Ｗｅｂサーバ４０経由で判定サーバ１０によりデータ保持部１３の隔離領域と保留領域に格納されたメールの管理をするための画面にアクセスすることができる。
判定サーバ１０は、Ｗｅｂサーバ４０経由で管理者端末５０からのリクエストに応じて、管理画面を表示させるための、ＨＴＭＬデータを生成し、Ｗｅｂサーバ４０経由で管理者端末５０に供給する。管理者端末５０は、供給されたＨＴＭＬデータに応じて、例えば図１５に示す管理画面５５を表示させる。
この管理画面５５には、データ保持部１３の隔離領域と保留領域に格納されたメール毎に、各々送信元メールアドレス表示領域５５１ａ、件名表示領域５５１ｂ、データ表示領域５５１ｃ、配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを有する表示５５１の一覧と、選択されたメールの本文が表示されるメール本文表示領域５５２が表示される。管理者端末５０の操作者は、信頼度データや送信元メールアドレス、メール本文から総合的に判断してメールを配信するか削除するかを選択し、対応する配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを指示する。
これにより、管理者端末５０の操作者が保留領域に格納されたメールの内容を確認し、問題がなければ状態を、例えば「配信可能」な状態に変更する。この状態の変化に応じて、判定サーバ１０は、当該メールを受信サーバ２０に配信する。管理者端末５０の操作者は隔離領域に格納されたメールについては、メールの内容を確認し削除することができる他、配信指示ボタンを押下することで特定のアドレスに転送することができる。
なお、上述の説明では、隔離または保留するメールをデータ保持部１３の隔離領域または保留領域に保存するようにしていたが、隔離フラグまたは保留フラグ等の情報を対応付けたメールをデータ保持部１３に保存しておき、各フラグ等の情報により隔離または保留したメールの判別を行ってもよい。
管理者端末５０では、上述の各種テーブルの保守管理等の他に、上述のＳ２２においてデータ保持部１３に格納されたメールの確認と状態の管理を行うことができるようになっている。
具体的には、管理者端末５０のＷｅｂブラウザを用いて、Ｗｅｂサーバ４０経由で判定サーバ１０によりデータ保持部１３の隔離領域と保留領域に格納されたメールの管理をするための画面にアクセスすることができる。
判定サーバ１０は、Ｗｅｂサーバ４０経由で管理者端末５０からのリクエストに応じて、管理画面を表示させるための、ＨＴＭＬデータを生成し、Ｗｅｂサーバ４０経由で管理者端末５０に供給する。管理者端末５０は、供給されたＨＴＭＬデータに応じて、例えば図１５に示す管理画面５５を表示させる。
この管理画面５５には、データ保持部１３の隔離領域と保留領域に格納されたメール毎に、各々送信元メールアドレス表示領域５５１ａ、件名表示領域５５１ｂ、データ表示領域５５１ｃ、配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを有する表示５５１の一覧と、選択されたメールの本文が表示されるメール本文表示領域５５２が表示される。管理者端末５０の操作者は、信頼度データや送信元メールアドレス、メール本文から総合的に判断してメールを配信するか削除するかを選択し、対応する配信指示ボタン５５１ｄ、削除指示ボタン５５１ｅを指示する。
これにより、管理者端末５０の操作者が保留領域に格納されたメールの内容を確認し、問題がなければ状態を、例えば「配信可能」な状態に変更する。この状態の変化に応じて、判定サーバ１０は、当該メールを受信サーバ２０に配信する。管理者端末５０の操作者は隔離領域に格納されたメールについては、メールの内容を確認し削除することができる他、配信指示ボタンを押下することで特定のアドレスに転送することができる。
なお、上述の説明では、隔離または保留するメールをデータ保持部１３の隔離領域または保留領域に保存するようにしていたが、隔離フラグまたは保留フラグ等の情報を対応付けたメールをデータ保持部１３に保存しておき、各フラグ等の情報により隔離または保留したメールの判別を行ってもよい。
【0044】
以上説明したように、本実施形態では、不正なメールと判定したメールについては、受信サーバ２０に転送せずに隔離し、不正なメールか否かまで判定をつけられないメールについてはメールの信用度を示す情報を付加して受信サーバ２０に転送することにより、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。これに加えて、疑わしいメールには確認メールを送信することによってさらに正確性を向上させることができる。
また、例えば受信サーバ２０に転送するメールに対して上述のメールの信用度を示す情報を付加するだけでも、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。
また、本実施形態では、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名及びＩＰアドレスと、出口サーバ７２までの間の経路が正確に把握できている既知の組織が送信元のメールである場合の経路判定を行うことによって、受信メールの正当性の判定において正確性を向上させることができる。
また、例えば受信サーバ２０に転送するメールに対して上述のメールの信用度を示す情報を付加するだけでも、メールの受信者（ユーザ端末６０のユーザ）が、受信したメールの信用度を判断することができ、受信メールの正当性の判定において正確性を向上させることができる。
また、本実施形態では、会社内あるいは関連会社、既存の取引先等の送信サーバ７１のホスト名及びＩＰアドレスと、出口サーバ７２までの間の経路が正確に把握できている既知の組織が送信元のメールである場合の経路判定を行うことによって、受信メールの正当性の判定において正確性を向上させることができる。
【0045】
なお、判定部１２は、図８のブラックリストテーブル１０６に記載した情報を、情報集約サーバ９０に送信する。判定サーバ１０は、組織毎に設けられているが、情報集約サーバ９０に集約されたブラックリストの情報を、要望・許諾条件等に応じて他の組織の判定サーバ１０に提供するようにしてもよい。この場合、判定サーバ１０には、提供されたブラックリストを登録する機能を設ける。他の組織のブラックリストテーブルを利用して、ブラックリストテーブル１０６の登録・管理等を行うことにより、ブラックリストテーブル１０６の精緻化が図れるため、作業負担を低減させることができる。
【符号の説明】
【0046】
１…ネットワーク、１０…判定サーバ、１１…履歴解析部、１２…判定部、１３…データ保持部、２０…受信サーバ、３０…送信サーバ、４０…Ｗｅｂサーバ、５０…管理者端末、６０…ユーザ端末、６１、メールクライアント、６１１…表示プラグイン、６２…表示部、７０、７４…送信端末、７１、７５…外部の送信サーバ、７２、７６…出口サーバ、８１…ＤＮＳサーバ、９０…情報集約サーバ
【要約】
ゲートウェイ装置は、送信元のドメイン毎のメールの送受信履歴に応じて送信元ドメインの信用度を評価するドメイン評価手段と、前記ドメイン評価手段による送信元ドメインの信用度に応じた送信元ドメインの信用度データを保持するドメイン信用度保持手段と、組織内の宛先メールアドレスの公開レベルに応じた宛先アドレスの信用度データを保持する宛先信用度保持手段と、受信したメールのヘッダから、当該メールの送信元のドメイン名と、前記組織内の宛先メールアドレスを抽出する抽出手段と、該抽出手段が抽出したドメイン名に対応する前記ドメイン信用度保持手段に保持されている送信元ドメインの信用度データと、前記抽出手段が抽出した前記組織内の宛先メールアドレスに対応する前記宛先アドレスの信用度データとに応じて、前記受信したメールの受信メール信用度データを求める算出手段とを備え、前記ドメイン評価手段が、送信数、受信数、スレッド平均、メールのやり取りをしている期間を示す取引期間のうちいずれか２つ以上を用いて送信元ドメインの信用度を評価する。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】