JP2019165352A - 情報処理装置、情報処理方法、プログラム及び記録媒体 - Google Patents

Abstract

【課題】ＳＰＦ認証とは異なる態様により、送信元のなりすまし等の電子メールの送信元が適切かどうかを判断する。【解決手段】情報処理装置は、社内扱いとしている一つ又は複数の第一端末１００に関する第一端末情報を記憶する記憶部１０と、社内扱いとなっていない第二端末２００であって、前記第一端末１００に接続された第二端末２００に関する第二端末情報を特定する特定部５０と、第二端末情報を用いて認証を行う認証部２０と、を有する。【選択図】図１

Description

本発明は、圧縮されたファイルを処理する情報処理装置、情報処理方法、プログラム及び記録媒体に関する。

従来から受信する電子メールによってウィルスに感染するリスクがあることから、このような電子メールに対してフィルタリングを行うことが提案されている。例えば、特許文献１では、いわゆる「なりすまし」の電子メールに対して対処することが開示されており、ユーザ宛の電子メールを記憶し、ユーザ宛の電子メールがなりすましメールであるか否かを判定するＷｅｂメールサーバを利用することが開示されている。このような「なりすまし」メールに対応するための技術としては、ＳＰＦ（Sender Policy Framework）認証も知られている。

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

本発明は、ＳＰＦ認証とは異なる態様により、送信元のなりすまし等の電子メールの送信元が適切かどうかを判断できる情報処理装置、プログラム、記録媒体及び情報処理方法を提供する。

本発明による情報処理装置は、
社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定する特定部と、
前記第二端末情報を用いて認証を行う認証部と、
を備えてもよい。

本発明による情報処理装置において、
前記特定部は、前記第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定してもよい。

本発明による情報処理装置において、
前記認証部は、前記ＦＱＤＮの完全一致又は部分一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行ってもよい。

本発明による情報処理装置において、
前記認証部は、前記ＦＱＤＮの部分一致を用いる場合には、サブドメインを削って後方一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行ってもよい。

本発明による情報処理装置において、
前記特定部は、前記第二端末情報に含まれるＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定してもよい。

本発明による情報処理装置において、
前記認証部は、前記エンベロープＦｒｏｍにおけるドメインの完全一致又は部分一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行ってもよい。

本発明による情報処理装置において、
前記認証部は、前記エンベロープＦｒｏｍにおけるドメインの部分一致を用いる場合には、サブドメインを削って後方一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行ってもよい。

本発明による情報処理装置において、
前記特定部は、前記第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定し、
前記認証部は、前記ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行い、前記ReceivedヘッダーにおけるＦＱＤＮを用いて前記ＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、エンベロープＦｒｏｍを用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行ってもよい。

本発明による情報処理装置は、
前記認証部による認証結果を用いて判定を行う判定部をさらに備え、
認証レベルが選択可能となり、
前記判定部は、選択された認証レベルと前記認証結果とに基づいて、判定結果を決定してもよい。

本発明による情報処理装置において、
認証レベルが選択可能となり、
少なくとも二つの異なる認証レベルにおいてＤＮＳ通信の上限回数が異なってもよい。

本発明による情報処理方法は、
社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定することと、
前記第二端末情報を用いて認証を行うことと、
を備えてもよい。

本発明によるプログラムは、
情報処理装置に情報処理方法を実行させるプログラムであって、
前記情報処理装置は、
社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定することと、
前記第二端末情報を用いて認証を行うことと、
を備えた情報処理方法を実行してもよい。

本発明による記録媒体は、
前述したプログラムを記録してもよい。

本発明の一態様によれば、

本発明の実施の形態による情報処理装置における処理の一例を説明するための図。 本発明の実施の形態で用いられうるReceivedヘッダーの記載内容を説明するための図。 本発明の実施の形態で用いられうる認証結果の一覧を表で示した図。 本発明の実施の形態で用いられうる情報処理装置を示したブロック図。 本発明の実施の形態で用いられうる認証結果、判定結果及び優先度の一例を表で示した図。 ＤＮＳレコード、ＴＸＴレコード、ＳＰＦレコード、Ａレコード及びＭＸレコードの関係を示した図。 本発明の実施の形態による処理の流れの一例を説明するための図。 本発明の実施の形態で用いられうる隔離を通知するための画面を示した図。 本発明の実施の形態で用いられうる認証結果又は判定結果を通知するための画面を示した図。 本発明の実施の形態による処理方法のフローの一例を示した図。 本発明の実施の形態で用いられうるＦＱＤＮ又はドメインを用いた処理方法のフローの一例を示した図。 本発明の実施の形態で用いられうるＴＸＴレコード評価を行うためのフローの一例を示した図。 本発明の実施の形態で用いられうるＳＰＦレコード評価を行うためのフローの一例を示した図。 本発明の実施の形態で用いられうる機構評価を行うためのフローの一例を示した図。 本発明の実施の形態で用いられうる送信元偽装を判定するためのフローの一例を示した図。

実施の形態
《構成》
以下、本発明に係る情報処理装置の実施の形態について、図面を参照して説明する。本実施の形態において「又は」は「及び」の意味も含んでいる。つまり、本実施の形態においてＡ又はＢとは、Ａ、Ｂ並びにＡ及びＢのいずれかを意味している。

本実施の形態の情報処理装置は一台の装置から構成されてもよいが、複数の装置から構成されてもよい。情報処理装置が複数の装置から構成される場合には、情報処理装置を構成する装置は異なる部屋又は異なる場所に設置されてもよく、情報処理装置の一部と情報処理装置の残部が遠隔地に配置されてもよい。

本実施の形態の情報処理装置は、図４に示すように、社内扱いとしている一つ又は複数の第一端末１００（図１参照）に関する第一端末情報を記憶する記憶部１０と、社内扱いとなっていない第二端末２００（図１参照）であって、第一端末１００に接続された第二端末２００に関する第二端末情報を特定する特定部５０と、第二端末情報に基づいて認証を行う認証部２０と、を有してもよい。本実施の形態では、一例として、図１に示す第一端末１００ａが特定部５０及び認証部２０を有している態様を用いて説明する。但し、このような態様に限られることはなく、第一端末１００ａが特定部５０及び認証部２０のいずれかだけを有してもよい。また、第一端末１００ａが記憶部１０を有してもよいが、サーバ等の別の装置が記憶部１０を有してもよい。

情報処理装置は、認証部２０による認証結果又は後述する判定部３０による判定結果に基づいて、受信した電子メールを受信先に配信したり、隔離領域に隔離したり、削除したりする等の各種の処理（アクション）を行う処理部４０を有してもよい。なお、隔離領域に電子メールが隔離された場合には、隔離通知が当該電子メールの受信先に配信されてもよい（図７参照）。隔離の通知は管理者に対して行われてもよい。管理者又は受信先への通知には、対象となっている電子メールの件名及び本文に関する情報が含まれてもよい。一例として図８に示されるような内容で通知されてもよい。

認証結果又は判定結果が理由とともに電子メールの受信先に送信されてもよい（図７参照）。認証結果又は判定結果は管理者に送信されてもよい。メール本文、件名等についてはリンク先を選択することで確認できるようになってもよい。一例として図９に示されるような内容で通知されてもよい。

特定部５０は、第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ（Fully Qualified Domain Name）及びグローバルＩＰアドレス等のＩＰアドレスを特定してもよい。また、特定部５０は、第二端末情報に含まれるグローバルＩＰアドレス等のＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定してもよい。また、特定部５０は、第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ、ＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定してもよい。

第一端末１００は例えばＭＴＡ（Mail Transfer Agent）であり、ホスティングサービスメールサーバが含まれてもよい。また、第二端末２００は例えばＭＴＡであり、ホスティングサービスメールサーバが含まれてもよい。本実施の形態では、経由してきた各ＭＴＡサーバが付与するReceivedヘッダーのうち、一番外側にある社内扱いのＭＴＡ（図１に示す態様では、IP:3.4.5.6）に接続してきた、社外の対抗ＭＴＡ（図１に示す態様では、IP:2.3.4.5）のＩＰアドレスを取得してもよい。

ＳＰＦ認証に使用するＩＰアドレスはひとつ前のＭＴＡのＩＰアドレスしか使用できず、ホスティングサーバー等を経由すると送信元IPアドレスが使用（特定）できない。これに対して、本実施の形態によれば、社内扱いの第一端末１００のうち最も社外に近い第一端末１００におけるReceivedヘッダーを解析することで、信頼できる接続元のＩＰアドレス情報、ＦＱＤＮ等を特定し、社外扱いの第二端末２００に直接接続されていない離れた第一端末１００からでも認証を行うことができる。なお、社内扱いされるＭＴＡ等の第一端末１００は、管理者等が図４に示す入力部９０を介して例えばＩＰアドレス等を入力することで記憶部１０に記憶されてもよい。社内扱いされる第一端末１００は、追加、修正、削除等が適宜行われてもよい。また、社内扱いされる第一端末１００は自動で識別されて、記憶部１０で記憶されてもよい。

記憶部１０はＩＰアドレス等を含む第一端末情報（図１参照）をリストとして記憶してもよい。第一端末１００がＭＴＡである場合には、リストに掲載されていないＭＴＡのうち、Receivedヘッダーの最上位に書かれたＩＰアドレスを持つＭＴＡが社外の対抗ＭＴＡとして特定されてもよい。なお、第一端末情報には、ＩＰアドレスの他に、ReceivedヘッダーにおけるＦＱＤＮ、エンベロープＦｒｏｍのドメイン等が含まれてもよい。

認証部２０は、ＦＱＤＮの完全一致又は部分一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。外部端末３００は例えばＤＮＳ（Domain Name System）サーバであってもよい。認証は例えばＳＰＦ（Sender Policy Framework）レコードを用いて行われてもよく、この場合には、ＩＰアドレスを用いた問い合わせとは例えばＳＰＦレコードの問い合わせを意味している。

認証部２０は、ＦＱＤＮの部分一致を用いる場合には、サブドメインを削って後方一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。一例としては、まずＦＱＤＮの完全一致で外部端末３００の特定を試み、ＦＱＤＮの完全一致で外部端末３００を特定できない場合にＦＱＤＮの部分一致、例えばサブドメインを削った後方一致で外部端末３００を特定してもよい。また、外部端末３００が特定されるまで繰り返し、サブドメインを削る処理が行われてもよい。図２に示す態様では、ＭＴＡリストを利用して社内扱いとされているＭＴＡを特定し、社外扱いとされているＭＴＡのうち最も社内に近いＭＴＡ（以下「社外境界ＭＴＡ」ともいう。）を特定する。そして、社外境界ＭＴＡのhosting.a.comというＦＱＤＮを使用してＤＮＳ通信を実行する。「hosting.a.com」というＦＱＤＮで外部端末３００を特定できなかった場合には、「hosting.」を削除して、「a.com」というＦＱＤＮを使用して再度ＤＮＳ通信を行う。サブドメインを削る処理は、有効な登録ドメイン（ccSDLやTDLを除く。図１１のＳ２１参照）まで実行してもよい。

認証部２０は、エンベロープＦｒｏｍにおけるドメインの完全一致又は部分一致を用いて特定された外部端末３００に対してＩＰアドレスに関する認証を依頼してもよい。一例としては、まずエンベロープＦｒｏｍにおけるドメインの完全一致で外部端末３００の特定を試み、エンベロープＦｒｏｍにおけるドメインで外部端末３００を特定できない場合にエンベロープＦｒｏｍにおけるドメインの部分一致、例えばサブドメインを削った後方一致で外部端末３００を特定してもよい。また、外部端末３００が特定されるまで繰り返し、サブドメインを削る処理が行われてもよい。

ReceivedヘッダーにおけるＦＱＤＮを用いて外部端末３００を特定することを優先し、ReceivedヘッダーにおけるＦＱＤＮを用いて外部端末３００を特定できない場合に、エンベロープＦｒｏｍにおけるドメインを用いて外部端末３００を特定するようにしてもよい（図１５参照）。但し、このような態様には限られず、エンベロープＦｒｏｍにおけるドメインを用いて外部端末３００を特定することを優先し、エンベロープＦｒｏｍにおけるドメインを用いて外部端末３００を特定できない場合に、ReceivedヘッダーにおけるＦＱＤＮを用いて外部端末３００を特定するようにしてもよい。

特定部５０が、第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定し、認証部２０が、ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。そして、ReceivedヘッダーにおけるＦＱＤＮを用いてＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、エンベロープＦｒｏｍのドメインを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。但し、このような態様には限られず、認証部２０が、エンベロープＦｒｏｍのドメインを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い、エンベロープＦｒｏｍのドメインを用いてＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。また、認証部２０は、ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行うとともに、エンベロープＦｒｏｍのドメインを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。

認証レベルは選択可能となってもよい（図３参照）。そして、少なくとも二つの異なる認証レベルにおいてＤＮＳ通信の上限回数が異なってもよい。一例としては、図３に示すように、認証レベルが４段階で設定可能となってもよい。第二認証レベル（図３の「標準」）の認証レベルは第一認証レベル（図３の「強」）より低く、第三認証レベル（図３の「中」）の認証レベルは第二認証レベルより低く、第四認証レベル（図３の「弱」）の認証レベルは第三認証レベルより低くてもよい。第二認証レベルでのＤＮＳ通信の上限回数は第一認証レベルでのＤＮＳ通信の上限回数よりも多くてもよく、一例として、第二認証レベルでのＤＮＳ通信の上限回数は２０回を超える数値ｍ（「ｍ」は２１以上の整数）であり、第一認証レベルでのＤＮＳ通信の上限回数は１０回である。なお、各認証レベルにおいてＤＮＳ通信の上限回数が異なってもよいし、複数の認証レベルのうち少なくとも２つにおいてＤＮＳ通信の上限回数が異なってもよい。上限を超えてＤＮＳ通信が行われる場合には、permerrorと判定してもよい。

なお、ＳＰＦ認証ではＳＰＦのフレームワークに基づき、定義通りに認証結果を返すことを目的としているが、正確に宣言しているユーザは５割前後と考えられることから、passの認証を取ることができない場合がある。また、ＳＰＦ認証では、例えば文法間違えをしていると認証はしてくれない。これに対して、本態様によれば、認証レベルを選択することで、適宜なレベルで認証を行うことができる。また、認証レベルを適宜選択することで、RFC7208通りに正確に宣言してなくても、宣言しようとしているＩＰアドレスを読み取れる限り読み取り、送信元を特定することに注力して、差出人のメールアドレスが他のドメイン名に「なりすまし」ていないか検出することもできる。なお、認証レベルは図４に示す入力部９０から入力可能となってよい。

図４に示すように、認証部２０による認証結果を用いて判定を行う判定部３０が設けられてもよい。判定部３０は、選択された認証レベルと認証結果とに基づいて、判定結果を決定してもよい。一例としては、判定部３０は、認証レベル（図３では４段階の認証レベル）と、「pass」、「fail」、「softfail」、「neutral」、「none」、「permerror」、「temperror」及び「empty」の認証結果とに基づいて、認証に成功したかどうかを判定してもよい。なお、図３では、判定部３０において認証に成功したと判定される場合には「〇」として示され、認証に失敗したと判定される場合には「×」として示されている。

図３に示す態様では、第一認証レベルでは１０回以下のＤＮＳ通信において、pass以外は認証ＮＧとして判定部３０で判定される。第二認証レベルではｍ回（「ｍ」は２１以上の整数）以下のＤＮＳ通信において、pass以外は認証ＮＧとして判定部３０で判定される。第三認証レベルではｍ回以下のＤＮＳ通信において、pass、neutral及びnone以外は認証ＮＧとして判定部３０で判定される。第四認証レベルではｍ回以下のＤＮＳ通信において、pass、softfail、neutral、none、permerror及びtemperror以外は認証ＮＧとして判定部３０で判定される。なお、発明者らが確認したところによると、１０回をＤＮＳ通信の上限として設定した場合には、passとなるべきケースであっても通信回数がオーバーすることでpermerrorとなってしまう場合が、passとならないケースの５０％程を占めることが判明した。他方、ｍ回のＤＮＳ通信を行うことで、passとなるべきケースであれば非常に多くのケースでpassとなることが判明した。

本実施の形態において、「pass」は認証に成功したことを意味し、「fail」は認証に失敗し、送信元が受信拒否を許容していることを意味し、「softfail」は認証に失敗したが、送信元が受信拒否について宣言しないことを意味し、「neutral」は認証に失敗したが、送信元が受信拒否しないことを意味し、「none」はＴＸＴレコードが存在するがＳＰＦレコードが公開されていないことを意味し、「permerror」はＳＰＦレコード文法ミス等の恒久的なエラーを意味し、「temperror」はＳＰＦレコード問い合わせタイムアウト等の一時的なエラーを意味し、「empty」はＴＸＴレコード自体が存在しないことを意味している。なお、ＴＸＴレコード自体が存在しない態様としては、ＤＮＳレコード自体が存在しないことも含まれている。

ＤＮＳレコード、ＴＸＴレコード、ＳＰＦレコード、Ａレコード、ＭＸレコード等の関係を図６に示す。ＤＮＳレコードの中にＴＸＴレコードが含まれ、ＴＸＴレコードの中にＳＰＦレコードが含まれるようになっている。RFC7208に基づいたＳＰＦ認証における「none」は認証するＳＰＦレコードが公開されていない態様を意味し、「neutral」と同等に扱われているところ、本実施の形態における「none」とは、前述したように、ＤＮＳレコードが存在するがＳＰＦレコードが公開されていない場合を意味し、「neutral」とは異なる取り扱いが行われる。また、RFC7208に基づいたＳＰＦ認証では「empty」という結果は存在しておらず、ＤＮＳレコード自体が存在していない場合には「none」として取り扱われている。

ＳＰＦ認証においては、RFC7208にしたがって認証結果をそのまま採用されるところ、本実施の形態では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果、passとなる場合以外では、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果が採用されてもよい。より具体的には、図５に示すように、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でfailの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはfailとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でsoffailの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはsoftfailとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でneutralの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはneutralとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でnoneの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはnoneとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でpermerrorの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはpermerrorとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でtemperrorの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはtemperrorとして取り扱われてもよい。ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果でemptyの場合では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果がpassとならないときにはemptyとして取り扱われてもよい。但し、これに限られることはなく、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果、passとなる場合以外では、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスを認証した結果が採用されてもよい。

また、認証結果に関する優先度が決められていてもよい。一例としては、図５に示すような優先度が決められていてもよい。この場合には、同じ送信元の同一又は異なるＳＰＦレコード内で異なる判定結果が得られたときに、優先度に従い、数字の低い方の認証結果を判定部３０が判定結果として採用してもよい。優先度は入力部９０からの入力によって適宜変更されてもよい。

また、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果及びエンベロープＦｒｏｍにおけるドメインを用いたＩＰアドレスの認証結果の両方をキュー等に記録し、記憶部１０で記憶してもよい（図１０参照）。そして、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果及びエンベロープＦｒｏｍにおけるドメインを用いたＩＰアドレスの認証結果のいずれか一方においてpassとなった場合に、passとなった方を優先して適用してもよい。両認証結果がpassとなった場合には、いずれを採用してもよい。

図１０に示す態様では、まず社外境界ＭＴＡ等の最も社内に近い第二端末２００のグローバルＩＰアドレスを接続元ＩＰアドレスとして取得する（Ｓ１１参照）。当該第二端末２００に関するReceivedヘッダーを検索し（Ｓ１２参照）、ReceivedヘッダーのＦＱＤＮを用いた認証結果を取得する（Ｓ１３参照）。また、最も社内に近い第二端末２００のエンベロープＦｒｏｍを取得し（Ｓ１４参照）、エンベロープＦｒｏｍのドメインを用いた認証結果を取得する（Ｓ１５参照）。そして、ReceivedヘッダーのＦＱＤＮを用いた認証結果とエンベロープＦｒｏｍのドメインを用いた認証結果の両方をキュー等に記録し、記憶部１０で記憶する。そして、ReceivedヘッダーのＦＱＤＮを用いた認証結果とエンベロープＦｒｏｍのドメインを用いた認証結果のいずれかにおいてpassとなった場合には、認証を行えたものとして認証部２０又は判定部３０で判断されてもよい。

このような態様に限られることはなく、社外境界ＭＴＡのＩＰアドレスを取得し、エンベロープＦｒｏｍにおけるドメインを用いたＩＰアドレスの認証を行う。その後で、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証を行う。そして、ReceivedヘッダーにおけるＦＱＤＮを用いたＩＰアドレスの認証結果及びエンベロープＦｒｏｍにおけるドメインを用いたＩＰアドレスの認証結果の両方をキュー等に記録し、記憶部１０で記憶されてもよい。このように両方の結果を記憶しておくことで、後々の確認に利用できる。

RFC7208に基づいたＳＰＦ認証では「redirect」では、引数で指定したドメインのＳＰＦレコードの判定結果を最終的な判定結果にしているところ、本実施の形態でも、「redirect」は引数で指定したドメインのＳＰＦレコードの判定結果を最終的な判定結果にしてもよい。但し、本実施の形態では、文法エラー等の「permerror」となるケースは「empty」と扱ってもよい。

RFC7208に基づいたＳＰＦ認証における「exp」では、引数で指定したドメインのTXTレコードを認証失敗時のエラーメッセージとしているところ、「exp」は認証ＯＫ／ＮＧに直接関わらないため、本実施の形態では「exp」を無視してもよい。

RFC7208に基づいたＳＰＦ認証では「all」は文末にのみ指定される機構で、他の機構が非該当判定だった場合に限定子に従った判定結果を該当させるところ、本実施の形態でも、「all」は文末にのみ指定される機構で、他の機構が非該当判定だった場合に限定子に従った判定結果を該当させてもよい。但し、本実施の形態では「+all」と書かれた場合には「permerror」としてもよい。「+all」とは全ての送信元を認証OKするという意味であり、送信元偽装手法として利用される可能性があるためである。

RFC7208に基づいたＳＰＦ認証における「include」では、指定したドメインの判定結果がpassの場合のみ限定子に従った判定結果を該当させ、pass以外の場合には非該当として扱うところ、本実施の形態における「include」では、指定したドメインの判定結果がpassの場合のみ限定子に従った判定結果を該当させ、pass以外の場合にはfail等の判定結果をそのまま引用してもよい。また、本実施の形態ではinclude先のall機構の評価を行わないようにしてもよい。

RFC7208に基づいたＳＰＦ認証では文法エラーはpermerrorとされるが、本実施の形態では、文法エラーを無視してもよい。

RFC7208に基づいたＳＰＦ認証では複数のＳＰＦレコードが存在する（例えばv=spf1で始まる構文が複数ある）場合にはpermerrorとされるが、本実施の形態では、判定結果がpassになるまですべてのＳＰＦレコードを評価し、passにならない場合には、認証部２０が、判定結果がpassになるまで全てのＳＰＦレコードを評価してもよい（図１２参照）。そして、全てのＳＰＦレコードに関してpassにならない場合に、判定部３０が、設定された認証レベルに応じた結果を判定してもよい。

記憶部１０は、信頼できる送信元情報を抽出されたリストをホワイトリストとして記憶してもよい。認証結果がpassとなった送信元情報を信頼できる送信元として扱ってもよい。ホワイトリストに該当するかどうかは、送信元IPアドレスと送信元ドメイン（エンベロープＦｒｏｍ）で特定してもよい。ホワイトリストに登録されている送信元に関しては、処理部４０による「隔離」「削除」等のアクションを抑止してもよい。

本実施の形態では、前述した情報処理装置に関するあらゆる態様における情報処理方法、当該情報処理装置を生成するためのプログラム、当該プログラムを記録したＵＳＢメモリ、ＣＤ、ＤＶＤ等を含む記録媒体も提供される。

本実施の形態の情報処理装置は、例えばサーバプログラム等のプログラムをインストールすることで生成される。このプログラムは電子メールで配信されてもよいし、所定のＵＲＬにアクセスしたうえでログインすることで入手できてもよいし、記録媒体に記録されてもよい。本実施の形態の情報処理方法は上記プログラムがインストールされた情報処理装置によって実施される。

《効果》
次に、上述した構成からなる本実施の形態による効果であって、未だ説明していないものを中心に説明する。なお、「効果」で述べるあらゆる構成は、本実施の形態の構成として利用することができる。

社内扱いとなっていない第二端末２００であって、第一端末１００に接続された第二端末２００に関する第二端末情報を特定し、第二端末情報に基づいて認証を行う態様を採用した場合には（図１参照）、信頼できる第二端末情報を用いて認証することができる。なお、社内扱いとなっているＭＴＡ等の第一端末１００に対しては認証を行わなくてもよい。

第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定して認証を行う態様を採用した場合には、信頼できるReceivedヘッダーにおける情報を用いて認証を行うことができる。一般的に、Receivedヘッダーは簡単に偽装可能なので、信頼することが難しいとされている。しかしながら、社内扱いされているＭＴＡ等の第一端末１００が記録したReceivedヘッダーが偽装されることはない。そして、社外境界ＭＴＡ（図１ではIP:2.3.4.5）等の第二端末２００が社内境界ＭＴＡ（図１ではIP:3.4.5.6）等の第一端末１００にＴＣＰコネクション等を行った際に社内境界ＭＴＡ等の第一端末１００が得たＦＱＤＮ及びＩＰアドレスは正しく記録されることになる。したがって、この態様を用いた場合には、信頼できるReceivedヘッダーにおける情報を用いて認証を行うことができる。また、ＳＰＦ認証で用いられているエンベロープＦｒｏｍについては偽装される可能性があるが、本態様のように社内境界ＭＴＡ（図１ではIP:3.4.5.6）等の第一端末１００によって特定される社外境界ＭＴＡ（図１ではIP:2.3.4.5）等の第二端末２００のＦＱＤＮ及びＩＰアドレスは偽装されることはないことから、正確な情報に基づいて認証を行うことができる。

認証部２０が、ＦＱＤＮの完全一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い態様を採用した場合には、完全なＦＱＤＮを用いてＤＮＳサーバ等の外部端末３００を特定することができる。他方、部分一致の特定でも許可する態様を採用した場合には、より高い確率で外部端末３００を特定することができる。また、部分一致の特定でも許可する態様を採用し、サブドメインを削って後方一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い態様を採用した場合には、より効率的に部端末を特定することができる。

特定部５０が、第二端末情報に含まれるＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定する態様を採用した場合には、エンベロープＦｒｏｍを用いてＤＮＳサーバ等の外部端末３００を特定することができる。なお、このＩＰアドレスは、社外境界ＭＴＡ等の第二端末２００に関してReceivedヘッダーに基づいて取得されたものを用いてもよい。

認証部２０は、エンベロープＦｒｏｍにおけるドメインの完全一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い態様を採用した場合には、完全なドメインを用いてＤＮＳサーバ等の外部端末３００を特定することができる。他方、部分一致の特定でも許可する態様を採用した場合には、より高い確率で外部端末３００を特定することができる。また、部分一致の特定でも許可する態様を採用し、サブドメインを削って後方一致を用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い態様を採用した場合には、より効率的に部端末を特定することができる。

特定部５０が社外境界ＭＴＡ等に関する第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定し、認証部２０がReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い、ReceivedヘッダーにおけるＦＱＤＮを用いてＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、エンベロープＦｒｏｍを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行う態様を採用した場合には（図１５参照）、ReceivedヘッダーにおけるＦＱＤＮを用いて特定されたＤＮＳサーバ等の外部端末３００によって認証を行えた旨（認証ＯＫ）の結果を取得できなかったときに、エンベロープＦｒｏｍを用いて特定されたＤＮＳサーバ等の外部端末３００に対してＩＰアドレスを用いた問い合わせを行うこととなる。このような態様では、Receivedヘッダーの情報に基づいて認証ＯＫの結果を取得できなかった場合に、エンベロープＦｒｏｍの情報に基づいて認証ＯＫの結果を取得しに行くことができ、手続きを簡易なものにしつつ、認証を極力取得するようにすることができる。

なお、このような態様とは異なり、特定部５０が社外境界ＭＴＡ等に関する第二端末情報に含まれるＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定し、認証部２０がエンベロープＦｒｏｍにおけるドメインを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行い、エンベロープＦｒｏｍにおけるドメインを用いてＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末３００に対してＩＰアドレスを用いた問い合わせを行ってもよい。このような態様では、エンベロープＦｒｏｍの情報に基づいて認証ＯＫの結果を取得できなかった場合に、Receivedヘッダーの情報に基づいて認証ＯＫの結果を取得しに行くことができる。このため、この態様でも、手続きを簡易なものにしつつ、認証を極力取得するようにすることができる。但し、エンベロープＦｒｏｍにおけるドメインに関しては社外のＭＴＡ等の第二端末２００によって偽装される可能性があるのに対して、社内境界ＭＴＡ等の社内扱いの境界にいる第一端末１００が取得するReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスに関しては偽装の可能性が極めて低いことから、この観点からすると、ReceivedヘッダーにおけるＦＱＤＮを優先的に用いる態様の方が有益である。

認証レベルが選択可能となり、少なくとも二つの異なる認証レベルにおいてＤＮＳ通信の上限回数が異なる態様を採用した場合には、認証レベルに応じてＤＮＳ通信の上限回数を変えることができる。

認証レベルが選択可能となり、判定部３０が選択された認証レベルと認証結果とに基づいて判定結果を決定する態様を採用した場合には、ユーザのニーズに沿った判定結果を出すことができる。

《方法》
次に、本実施の形態によって採用されうる方法の一例について説明する。なお、「方法」で述べるあらゆる構成は、本実施の形態の構成として利用することができる。

図１０におけるＦＱＤＮ評価又はドメイン評価では、図１１に示すような処理が行われてもよい。

まず、ｃｃＳＬＤ／ＴＬＤ判定を行う（図１１のＳ２１参照）。ｃｃＳＬＤ／ＴＬＤ判定では、いわゆる有効なドメインの範囲でＴＸＴレコードの有無を評価するために、評価除外条件を判定するために行われる。通常は、最初のうちはｃｃＳＬＤ／ＴＬＤ判定はＮｏとなり、ドメインを削除していくことで「あるタイミング」でＹｅｓとなる。そして、このようにｃｃＳＬＤ／ＴＬＤ判定がＹＥＳとなると、既に得ている評価結果で確定させる。

ｃｃＳＬＤ／ＴＬＤ判定がＮｏとなると、次にＤＮＳ問い合わせを行い（図１１のＳ２２参照）、ＴＸＴレコード評価を行う（図１１のＳ３０参照）。ＴＸＴレコード評価でpassの場合には評価結果を確定する。pass以外の場合には、次の階層を用いて同じ工程を繰り返し行う。ここでいう階層というのは、ＦＱＤＮの完全一致及び部分一致、エンベロープＦｒｏｍにおけるドメインの完全一致及び部分一致を意味している。ＦＱＤＮ評価では、まずＦＱＤＮの完全一致を用いて外部端末３００を特定し、ＦＱＤＮの完全一致で外部端末３００を特定できない場合にはＦＱＤＮの部分一致で外部端末３００を特定する。ＦＱＤＮの部分一致においては、サブドメインを前方から徐々に削っていき、後方一致によって外部端末３００を特定するようにする。ドメイン評価でも同様であり、ドメイン評価では、まずエンベロープＦｒｏｍのドメインの完全一致を用いて外部端末３００を特定し、ドメインの完全一致で外部端末３００を特定できない場合にはドメインの部分一致で外部端末３００を特定する。ドメインの部分一致においては、サブドメインを前方から徐々に削っていき、後方一致によって外部端末３００を特定するようにする。

図１１のＴＸＴレコード評価においては、図１２に示すような処理が行われてもよい。複数のＳＰＦレコード（例えばv=spf1で始まる構文が複数ある）場合には、図１２における「ＳＰＦレコード数ループ」及び「次の要素へ」の間で繰り返し処理が行われる。

ＳＰＦレコードの有無を確認し（図１２のＳ３１参照）、ＳＰＦレコードが無い場合にはemptyとう評価結果が記憶部１０に記憶される。

ＳＰＦレコードが有る場合には、ＳＰＦレコードの構文要素を分解し（図１２のＳ３２参照）、ＳＰＦレコード評価を行う（図１２のＳ４０参照）。ＳＰＦレコード評価によってpassの結果を得た場合には評価結果を記憶部１０に格納する。他方、ＳＰＦレコード評価によってpass以外の結果を得た場合には、次のレコード（次のv=spf1で始まる構文）について同じ処理を繰り返し行う。なお、次のレコード（次のv=spf1で始まる構文）が存在しない場合には、ＴＸＴレコード評価を終了し、pass以外からなる評価結果を記憶部１０に格納する。

図１２のＳＰＦレコード評価においては、図１３に示すような処理が行われてもよい。

要素が修飾子であるかを確認する（図１３のＳ４３参照）。redirectの場合には、指定されたドメイン先のＳＰＦレコードの評価結果に従うため再帰呼出を行い、図１２の「ＳＰＦレコードの構文要素分解」に戻る。修飾子がexpの場合には「無視」することから次の要素に対する評価を行う。redirect及びexpで無い場合には、構成評価を行う（図１３のＳ５０参照）。構成評価によってpassの結果を得た場合には、ＳＰＦレコード評価を終了し、passという評価結果を記憶部１０に格納する。pass以外の場合には、次の要素（例えば、同じv=spf1に含まれる次の要素）があるかを判断する（図１３のＳ４１参照）。次の要素があれば、前述した処理を繰り返し行う。他方、次の要素が無ければ、include先のallであるかを判断する（図１３のＳ４５参照）。include先のallである場合には構成評価を行う（図１３のＳ５０参照）。include先のallでなければ既に得られている評価結果を記憶部１０に格納する。

図１３の各構成評価においては、図１４に示すような処理が行われてもよい。

まず、限定子処理を行う（図１４のＳ５１参照）。次に、機構がincludeであるかを判断する（図１４のＳ５２参照）。機構がincludeの場合には、include先ドメインのＳＰＦレコードの評価結果に従うため再帰呼出を行い、図１２の「ＳＰＦレコードの構文要素分解」に戻る。

機構がincludeでない場合には、機構がallであるかを判断する（図１４のＳ５３参照）。機構がallである場合には、include先のallであるかを判断し（図１４のＳ５６参照）、include先のallである場合には評価結果を格納する。include先のallで無い場合には、機構が+all又はallであるかを判断し（図１４のＳ５７参照）、機構が+all又はallの場合には、評価結果をpermerrorとする（図１４のＳ５８参照）。機構が+all及びallではない場合には、評価結果を記憶部１０に格納する。機構がinclude及びallで無い場合には、その他機構評価を行い（図１４のＳ５４参照）、評価結果を記憶部１０に格納する。評価結果がpassの場合には、図１３における各機構評価がpassとなり、評価結果が格納される。評価結果がpass以外の場合には、図１３における各機構評価がpass以外となり、前述したように、次の要素（例えば、同じv=spf1に含まれる次の要素）に対してＳＰＦレコード評価を行う。なお、機構の評価はＳＰＦ認証で用いられているものに準じ、「all」、「include」、「a」、「mx」、「ptr」、「ip4」、「ip6」、「exists」等から構成されてもよい。限定子の評価としてはRFC7208に準じてもよい。

ReceivedヘッダーにおけるＦＱＤＮを用いて外部端末３００を特定することを優先し、ReceivedヘッダーにおけるＦＱＤＮを用いて外部端末３００を特定できない場合に、エンベロープＦｒｏｍにおけるドメインを用いて外部端末３００を特定する態様の一例について、図１５を用いて説明する。

まず、ＩＰアドレスを取得済みかどうか判定部３０が判断する（図１５のＳ６１参照）。ＩＰアドレスを取得できていない場合には認証できなかった（認証ＮＧ）と判定部３０が判断する。ＩＰアドレスを取得できている場合には、当該ＩＰアドレスがプライベートＩＰアドレスかどうかを判定部３０が判断する（図１５のＳ６２参照）。プライベートＩＰアドレスの場合には認証できたもの（認証ＯＫ）と判定部３０が判定する。

ＩＰアドレスがプライベートＩＰアドレスでない場合には、設定された認証強度（図３参照）に応じてＦＱＤＮを用いた判定を行う（図１５のＳ６３参照）。認証ＮＧの場合には、エンベロープＦｒｏｍにおけるドメインを用いて、設定された認証強度（図３参照）に応じて判定を行う（図１５のＳ６５参照）。エンベロープＦｒｏｍにおけるドメインを用いた認証では、前述したように、社外境界ＭＴＡ等の第二端末に関するReceivedヘッダーにおけるＩＰアドレスを用いてもよい。

上述した実施の形態の記載及び図面の開示は、特許請求の範囲に記載された発明を説明するための一例に過ぎず、上述した実施の形態の記載又は図面の開示によって特許請求の範囲に記載された発明が限定されることはない。出願当初の特許請求の範囲の記載は本件特許明細書の範囲内で適宜変更することもでき、その範囲を拡張することもできる。

上記各実施の形態の認証部２０、判定部３０、処理部４０、特定部５０、記憶部１０等を含む各構成要素は、ＩＣチップ、ＬＳＩ等の集積回路等に形成された論理回路（ハードウェア）や専用回路によって実現してもよいし、ＣＰＵ、メモリ等を用いてソフトウェアによって実現してもよい。また、各構成要素は、１又は複数の集積回路により実現されてよく、複数の構成要素が１つの集積回路によって実現されてもよい。また、認証部２０、判定部３０、処理部４０、特定部５０等を含む構成要素として制御部が観念されてもよい。

１０ 記憶部
２０ 認証部
３０ 判定部
４０ 処理部
５０ 特定部

Claims (13)

1. 社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定する特定部と、
   前記第二端末情報を用いて認証を行う認証部と、
   を備えることを特徴とする情報処理装置。
2. 前記特定部は、前記第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定することを特徴とする請求項１に記載の情報処理装置。
3. 前記認証部は、前記ＦＱＤＮの完全一致又は部分一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行うことを特徴とする請求項２に記載の情報処理装置。
4. 前記認証部は、前記ＦＱＤＮの部分一致を用いる場合には、サブドメインを削って後方一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行うことを特徴とする請求項３に記載の情報処理装置。
5. 前記特定部は、前記第二端末情報に含まれるＩＰアドレス及びエンベロープＦｒｏｍにおけるドメインを特定することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記認証部は、前記エンベロープＦｒｏｍにおけるドメインの完全一致又は部分一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行うことを特徴とする請求項５に記載の情報処理装置。
7. 前記認証部は、前記エンベロープＦｒｏｍにおけるドメインの部分一致を用いる場合には、サブドメインを削って後方一致を用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行うことを特徴とする請求項６に記載の情報処理装置。
8. 前記特定部は、前記第二端末情報に含まれるReceivedヘッダーにおけるＦＱＤＮ及びＩＰアドレスを特定し、
   前記認証部は、前記ReceivedヘッダーにおけるＦＱＤＮを用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行い、前記ReceivedヘッダーにおけるＦＱＤＮを用いて前記ＩＰアドレスによる認証を行えた旨の結果を取得できない場合に、エンベロープＦｒｏｍを用いて特定された外部端末に対して前記ＩＰアドレスを用いた問い合わせを行うことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記認証部による認証結果を用いて判定を行う判定部をさらに備え、
   認証レベルが選択可能となり、
   前記判定部は、選択された認証レベルと前記認証結果とに基づいて、判定結果を決定することを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 認証レベルが選択可能となり、
    少なくとも二つの異なる認証レベルにおいてＤＮＳ通信の上限回数が異なることを特徴とする請求項９に記載の情報処理装置。
11. 社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定することと、
    前記第二端末情報を用いて認証を行うことと、
    を備えることを特徴とする情報処理方法。
12. 情報処理装置に情報処理方法を実行させるプログラムであって、
    前記情報処理装置は、
    社内扱いとしている一つ又は複数の第一端末に関する第一端末情報を用いて、社内扱いとなっていない第二端末であって前記第一端末に接続された第二端末に関する第二端末情報を特定することと、
    前記第二端末情報を用いて認証を行うことと、
    を備えた情報処理方法を実行することを特徴とするプログラム。
13. 請求項１２に記載のプログラムを記録した記録媒体。