JP2010134810A - 宛先正否判定システム - Google Patents

Abstract

【課題】電子メールの宛先を分類するための機械学習の判定精度を上げること、特に、電子メールの宛先に特に問題が無いにもかかわらず誤っていると判定されてしまう確率を下げる。
【解決手段】入力された電子メールのメールヘッダから宛先の名称を示す第一の名称文字列を取得し、その電子メールのメール本文から宛先の名称を示す第二の名称文字列を取得し、第一の名称文字列と第二の名称文字列との比較である名称比較を行う。名称比較の結果、及び、入力された電子メールの宛先を分類するための機械学習での判定結果のいずれかが、正しいとの判定結果であれば、入力された電子メールの宛先が正しいと判定する。
【選択図】図３

Description

本発明は、電子メールの宛先の正否を判定するための技術に関する。

例えば、特許文献１には、電子メールの宛先が正しいか否かの判定を行うシステムに関する技術が開示されている。特許文献１に記載のシステムは、予め、宛先ごとにその宛先に対応したキーワードを登録しておき、判定対象の電子メールの宛先に対応したキーワードが、その電子メールのメール本文に含まれているか否かを判定することにより、宛先の正否を判定する。

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

しかしながら、上述した技術のように、宛先ごとにその宛先に対応したキーワードを予め登録しておく（即ち、キーワードが登録された外部辞書を予め用意しておく）ことは、システムの管理者にとって面倒であり、また、適切なキーワードを選択することは、困難である。

一方、入力された電子メールの宛先を分類するための機械学習が知られている。この種の機械学習としては、ベイズ型の機械学習や、ＳＶＭ（Support Vector Machine）がある。機械学習の種類によっては、上述したような外部辞書を用いることなく電子メールの宛先を分類することができるが、判定の精度は必ずしも高くはない。このため、電子メールの宛先に特に問題が無いにも関わらず、誤っていると判定されてしまうケースがある。電子メールの宛先に特に問題が無いにもかかわらず誤っていると判定されると、電子メールを送信したいユーザが、送信されても問題のない電子メールであるにもかかわらず、警告を受けたり電子メールの送信が保留されたりしてしまうことになる。

そこで、本発明の目的は、電子メールの宛先を分類するための機械学習の判定精度を上げること、特に、電子メールの宛先に特に問題が無いにもかかわらず誤っていると判定されてしまう確率を下げることにある。

入力された電子メールのメールヘッダから宛先の名称を示す第一の名称文字列を取得し、その電子メールのメール本文から宛先の名称を示す第二の名称文字列を取得し、第一の名称文字列と第二の名称文字列との比較である名称比較を行う。名称比較の結果、及び、入力された電子メールの宛先を分類するための機械学習での判定結果のいずれかが、正しいとの判定結果であれば、入力された電子メールの宛先が正しいと判定する。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。

図１は、本発明の一実施形態に係るネットワークシステム１の構成例を示す図である。

本実施形態に係るネットワークシステム１は、例えば、社内ネットワーク１１と、社外ネットワーク（インターネット及び社内ネットワーク１１とは異なる外部のイントラネットを含む）１２とから構成されている。社内ネットワーク１１には、例えば、一以上の社内端末２と、宛先正否判定システム３と、メールサーバ４とが接続される。一方、社外ネットワーク１２には、例えば、一以上の社外端末５が接続される。

社内端末２は、社内ネットワーク１１に接続された端末装置である。また、社外端末５は、社外ネットワーク１２に接続された端末装置である。両端末２，５は、電子メールの送受信を行う機能を有するアプリケーション（メーラー）を備えており、電子メールの送受信が可能である。

メールサーバ４は、社内端末２から送信される電子メール及び社内端末２が受信する電子メールの送受信を管理するサーバ装置である。

宛先正否判定システム３は、メールサーバ４が送受信を管理する電子メールについてその宛先が正しいか否かの判定を行うシステム（サーバ装置）である。以下の説明では、宛先正否判定システム３が行う、宛先正否判定システム３に入力された電子メールの宛先が正しいか否かを判定する処理を「宛先正否判定処理」と呼ぶ。また、宛先正否判定処理の対象とされる電子メールを「対象メール」と呼ぶ。例えば、宛先正否判定システム３は、対象メールについて宛先正否判定処理を行った結果、ＯＫ（宛先が正しい）と判定された場合に、対象メールを送信し（すなわち社内ネットワーク１１の外に出力し）、ＮＧ（宛先が誤っている）と判定された場合に、対象メールを送信しないこととすることができる。対象メールは、例えば、送信メール（具体例として、アウトバウンドメール、即ち、社内ネットワーク１１から社外ネットワーク１２へ送信される電子メール（言い換えれば、社内端末２から社外端末５へ送信される電子メール））である。

尚、本実施形態では、宛先正否判定システム３及びメールサーバ４は、異なるサーバ装置とされたが、両装置３，４の機能が、一つのサーバ装置において実現されてもよい。

図２は、宛先正否判定システム３の構成例を示す図である。

宛先正否判定システム３は、例えば、ＣＰＵ３１と、メモリ３２と、外部の装置との通信を制御する装置である通信Ｉ／Ｆ（インターフェイス）部３３とを備える。

メモリ３２には、例えば、種々のコンピュータプログラムや、ＣＰＵ３１による処理に使用される種々のデータ等が記憶される。コンピュータプログラムとしては、例えば、機械学習プログラム３２２、宛先名称判定プログラム３２３、宛先ドメイン判定プログラム３２４及び総合判定プログラム３２５が記憶される。

ＣＰＵ３１は、メモリ３２に記憶されているプログラムを実行することにより、宛先正否判定処理を行うことができる。例えば、ＣＰＵ３１は、機械学習プログラム３２２を実行することにより、機械学習部３１２の機能を実現し、宛先名称判定プログラム３２３を実行することにより、宛先名称判定部３１３の機能を実現し、宛先ドメイン判定プログラム３２４を実行することにより、宛先ドメイン判定部３１４の機能を実現し、総合判定プログラム３２５を実行することにより、総合判定部３１５の機能を実現する。宛先正否判定処理では、機械学習部３１２によって機械学習処理が行われ、宛先名称判定部３１３によって宛先名称判定処理が行われ、宛先ドメイン判定部３１４によって宛先ドメイン判定処理が行われる。

以下、図３を参照して、宛先正否判定処理における機械学習処理、宛先名称判定処理及び宛先ドメイン判定処理を説明し、その際に、機械学習部３１２、宛先名称判定部３１３、宛先ドメイン判定部３１４及び総合判定部３１５について説明する。なお、本実施形態の説明では、対象のメールのＴＯ及びＣＣを「宛先」と総称しており、以下の説明では、対象メールのメールヘッダの“ＴＯ”及び“ＣＣ”に設定されたデータを「宛先データ」と言う。宛先データには、例えば、宛先を示すメールアドレスと、そのメールアドレスに割り当てられた表示名とが含まれる。ここで、表示名とは、宛先の名称（例えば、姓、名、氏名、愛称等）を示す文字列のことである。また、メールアドレスにおけるアットマークよりも後の文字列は、宛先のドメイン（宛先の住所）を示している。また、メールアドレスにおけるアカウント名（すなわちアットマークよりも前の文字列）は、表示名と同様に、宛先の名称を示している場合がある。そこで、以下、宛先の名称を示す文字列、即ち、表示名及びアカウント名を「名称文字列」と呼ぶ。また、宛先のドメインを示す文字列、即ち、メールアドレスにおけるアットマークよりも後の文字列を「ドメイン文字列」と呼ぶ。

まず、機械学習処理について説明する。機械学習処理は、対象メールの宛先を分類するための処理である。一般に、機械学習処理では、予め用意されたカテゴリのどれに分類されるかが判定されるが、本実施形態での機械学習処理では、カテゴリとして宛先のドメインが採用されている。機械学習の手法としては、ＳＶＭ（Support Vector Machine）或いはベイズ型など種々の手法を採用可能である。

機械学習判定処理において、機械学習部３１２は、対象メールのメール本文の内容に基づいて宛先のドメインを推定し、対象メールの宛先のドメインが、推定されたドメインに一致するか否かを判定する。具体的には、機械学習部３１２は、メールヘッダの宛先データに含まれるドメイン文字列を抽出し、且つ、メール本文に含まれる単語を抽出する。機械学習部３１２は、抽出した単語をベクトル化（各単語の種類毎に次元をつくり、各次元の値を各単語の出現数とする）し、メール本文に含まれる単語のそれぞれのベクトルを参照してメール本文の内容を把握し、その内容に適合したドメインを推定する。そして、機械学習部３１２は、上記抽出されたドメイン文字列が示すドメインが、推定されたドメインと一致しているか否かを判定する。対象メールの宛先のドメインが、推定されたドメインと一致している場合は、機械学習部３１２は、機械学習での判定結果としてＯＫ（宛先のドメインが正しいとの判定結果）を出力する。一方、対象メールの宛先のドメインが、推定されたドメインと一致していない場合は、機械学習部３１２は、機械学習での判定結果としてＮＧ（宛先のドメインが誤っているとの判定結果）を出力する。

次に、宛先名称判定処理について説明する。宛先名称判定処理は、対象メールの宛先の名称が正しいか否かを判定する処理である。宛先名称判定部３１３は、メールヘッダにおける宛先の名称文字列（以下、「第一の名称文字列」）と、メール本文における宛先の名称文字列（以下、「第二の名称文字列」）とが一致するか否かを判定する。

具体的には、宛先名称判定部３１３は、メールヘッダに設定された宛先データから、第一の名称文字列を抽出する。また、宛先名称判定部３１３は、メール本文から、第二の名称文字列を抽出する。その後、宛先名称判定部３１３は、第一の名称文字列と第二の名称文字列とを比較する宛先名称比較を行う。宛先名称比較の結果、第一及び第二の名称文字列が互いに一致している場合は、宛先名称判定部３１３は、判定結果としてＯＫ（宛先の名称が正しいとの判定結果）を出力する。一方、第一及び第二の名称文字列が互いに一致していない場合は、宛先名称判定部３１３は、判定結果としてＮＧ（宛先の名称が誤っているとの判定結果）を出力する。

次に、宛先ドメイン判定処理について説明する。宛先ドメイン判定処理は、対象メールの宛先のドメインが正しいか否かを判定する処理である。宛先ドメイン判定部３１４は、メールヘッダにおける宛先のドメイン文字列（以下、「第一のドメイン文字列」）と、メール本文における宛先のドメイン文字列（以下、「第二のドメイン文字列」）とが一致するか否かを判定する。

具体的には、宛先ドメイン判定部３１４は、メールヘッダに設定された宛先データから、第一のドメイン文字列を抽出する。また、宛先ドメイン判定部３１４は、メール本文から、第二のドメイン文字列を抽出する。その後、宛先ドメイン判定部３１４は、第一のドメイン文字列と第二のドメイン文字列とを比較するドメイン比較を行う。第一及び第二のドメイン文字列が互いに一致している場合は、宛先ドメイン判定部３１４は、判定結果としてＯＫ（宛先のドメインが正しいとの判定結果）を出力する。一方、第一及び第二のドメイン文字列が互いに一致していない場合は、宛先ドメイン判定部３１４は、判定結果としてＮＧ（宛先のドメインが誤っているとの判定結果）を出力する。

総合判定部３１５は、機械学習処理での判定結果、宛先名称判定処理での判定結果、及び宛先ドメイン判定処理での判定結果に基づいて、宛先正否判定処理の判定結果を決定する。具体的には、例えば、総合判定部３１５は、機械学習処理での判定結果、宛先名称判定処理での判定結果、及び宛先ドメイン判定処理での判定結果の少なくとも一つがＯＫの場合に、対象メールの宛先が正しいと判定し、それらの判定結果の全てがＮＧの場合に、対象メールの宛先が誤っていると判定することができる。

以上のように宛先正否判定処理が行われることにより、機械学習処理での判定結果を基にした宛先判定を好適にサポートすることができる。即ち、機械学習処理での判定結果をそのまま宛先正否判定処理の結果とすると、宛先が正しいにもかかわらず誤っていると判定される第一の問題ケースと、宛先が誤っているのに正しいと判定される第二の問題ケースとのいずれかが生じ得るが、本実施形態のように、三つの判定結果の少なくとも一つがＯＫの場合に対象メールの宛先が正しいと判定するようにすれば、第一の問題ケースが生じる確率（以下、「第一の確率」）を低くすることができる。宛先が正しいにもかかわらず誤っていると判定されると、対象メールを送信したいユーザが、宛先が正しくて送信しても問題のない電子メールであるにもかかわらず、警告を受けたり対象メールの送信が保留されたりしてしまうことになる。本実施形態によれば、このようなユーザにとっての不便を減少させることができる。

図４は、宛先名称判定処理の詳細を説明する図である。図４を参照して、宛先名称判定処理の流れを説明する。

宛先名称判定部３１３は、対象メールのメールヘッダに設定された宛先データから、その宛先データに含まれる第一の名称文字列を抽出する（Ｓ１０１）。図４の例では、メールヘッダの“ＴＯ”には、第一の名称文字列として、表示名“Ａ社黒田俊介様”と、アカウント名“kuroda_shunsuke”が含まれている。また、メールヘッダの“ＣＣ”には、第一の名称文字列として、表示名“鈴木”と、アカウント名“suzuki”とが含まれている。従って、本例の場合、第一の名称文字列として、“Ａ社黒田俊介様”、“kuroda_shunsuke”、“鈴木”及び“suzuki”の四つの名称文字列が抽出される。

次に、宛先名称判定部３１３は、Ｓ１０１で抽出された名称文字列のうちローマ字表記となっていない文字列を、ローマ字表記に変換する（Ｓ１０２）。本例の場合は、“Ａ社黒田俊介様”が“Asyakurodasyunsukesama”に変換され、“鈴木”が“suzuki”に変換される。

次に、宛先名称判定部３１３は、ローマ字表記に変換された名称文字列における表記ゆれ対象を、その表記ゆれの種類に対応した統一表記に変換する（Ｓ１０３）。これにより、宛先名称判定の精度を高めることができる。具体的には、アカウント名とメール本文に記載の宛先の名称とが実質的に同一であっても、Ｓ１０２でのローマ字表記変換処理の結果、表記ゆれ対象において文字に違いが生じることがあり、その結果、Ｓ１１０での比較の結果としてＯＫが得られるべきところＮＧが得られてしまうおそれがあるが、Ｓ１０３の処理が行われることにより、表記ゆれ対象における表記がその表記ゆれの種類に対応した統一表記に変換されるため、文字に違いがなくなり、それ故、Ｓ１１０での比較で一致が得られる確率が高まる。

本例では、下記（Ａ）乃至（Ｃ）の処理が行われる。
（Ａ）濁音（及び半濁音）が清音に統一される（清音が濁音（又は半濁音）に統一されても良い）；
（Ｂ）シ及びチの子音による拗音の表記が“ｈ”を用いた表記に変換される；
（Ｃ）アンダーバーが除去される。

このため、“kuroda_shunsuke”が“kurotashunsuke”に変換され、“Asyakurodasyunsukesama”が“Ashakurotashunsukesama”に変換され、“suzuki”が“susuki”に変換される。

一方で、宛先名称判定部３１３は、対象メールのメール本文から、対象メールの宛先の名称を示す文字列と推定される文字列、つまり第二の名称文字列を抽出する。具体的には、宛先名称判定部３１３は、以下のような処理を行う。

即ち、宛先名称判定部３１３は、対象メールのメール本文から、メール本文の先頭からＮ行に存在する文字列を抽出する（Ｓ１０４）。Ｎは１以上の整数であって、メール本文を構成する行数よりも小さい整数であり、好適には、先頭から数行程度となるような値（例えばＮ＝１以上５以下）である。本例では、Ｎ＝２であり、故に、“Ａ社黒田俊介様”と“お世話になっております。”が抽出される。

次に、宛先名称判定部３１３は、Ｓ１０４で抽出された文字列から、敬称（“様”や“さん”等）を含んだ文字列（例えば、一文）を抽出する（Ｓ１０５）。本例では、例えば、“Ａ社黒田俊介様”が抽出される。

次に、宛先名称判定部３１３は、Ｓ１０５で抽出された文字列に対して形態素解析を行う（Ｓ１０６）。

次に、宛先名称判定部３１３は、Ｓ１０６の形態素解析において固有名詞且つ人名と解析された単語を示す文字列を抽出する（Ｓ１０７）。このＳ１０７で抽出された文字列が、第二の名称文字列となる。本例の場合、第二の名称文字列は、“黒田俊介”となる。なお、Ｓ１０６及びＳ１０７と同様の処理が、メールヘッダの表示名における文字列（“Ａ社黒田様”及び“鈴木”）に対して行われても良い。

このように、本実施形態では、メール本文の先頭数行に含まれる、敬称が付けられた人名を示す文字列が、第二の名称文字列である。これは、一般に、電子メールの書き出し部分に、相手方の名称を記載することが多いという実情に基づいている。このような実情に着目し、文字列の抽出範囲をメール本文の先頭からＮ行に絞り込むことで、処理の高速化が期待できる。

その後、宛先名称判定部３１３は、Ｓ１０７で抽出された第二の名称文字列のうちローマ字表記となっていないものを、ローマ字表記に変換する（Ｓ１０８）。本例の場合は、“黒田俊介”が“kurodasyunsuke”に変換される。

次に、宛先名称判定部３１３は、ローマ字表記に変換された第二の名称文字列おける表記ゆれ対象を、その表記ゆれの種類に対応した統一表記に変換する（Ｓ１０９）。前述したルールに従えば、本例の場合、“kurodasyunsuke”が“kurotashunsuke”に変換される。

その後、宛先名称判定部３１３は、Ｓ１０３で得られた文字列（以下、「変換後の第一の名称文字列」）とＳ１０９で得られた文字列（以下、「変換後の第二の名称文字列」）とを比較して、判定結果を決定する（Ｓ１１０、Ｓ１１１）。例えば、宛先名称判定部３１３は、変換後の第一の名称文字列のいずれかが、変換後の第二の名称文字列のいずれかと一致した場合に、宛先の名称は正しいと判定することができる。つまり判定結果としてＯＫを出力することができる。このようなルールによれば、本例では、変換後の第一の名称文字列“Ashakurotashunsukesama”中の“kurotashunsuke”と変換後の第二の名称文字列“kurotashunsuke”とが一致するため、宛先の名称は正しいと判定される。尚、宛先名称判定部３１３は、変換後の第一の名称文字列と変換後の第二の名称文字列とが完全に一致していなくとも、例えば、両文字列が類似している（例えば類似度が所定の類似度以上である）場合に、判定結果としてＯＫが出力されても良い。

以上が、宛先名称判定処理の流れの説明である。なお、前述の例では、アットマーク前のローマ字列におけるアンダーバー（及び／又は、ハイフン、スペース等の区切り用のキャラクタ）が除去されるが、それに代えて、アンダーバー（及び／又は、ハイフン、スペース等の区切り用のキャラクタ）の前後の単語がそれぞれ第一の名称文字列（“kuroda”と“shunsuke”）として取得されても良い。一方、Ｓ１０６で、姓名が区別されて、“黒田”と“俊介”が取得され、それぞれの文字列に対してＳ１０８及びＳ１０９が行われても良い。これにより、Ｓ１１０で一致が得られる確率が高まる。

宛先名称判定処理での判定結果がＯＫとなるためのルールは、後述の宛先ドメイン判定処理での判定結果がＯＫとなるためのルールに比べて緩いルールとなっている。具体的には、少なくとも一つの第一の名称文字列が少なくとも一つの第二の名称文字列に一致すれば、宛先名称判定処理での判定結果がＯＫとされる。その理由は、ＴＯ及びＣＣにおける全ての表示名又はアカウント名が、メール本文中の宛先「〜様」と一致するケースは少ないと考えられるからである（例えば、ＣＣに対応した宛先をメール本文に記載することは少ないと考えられるからである）。このため、第一の確率を下げるという効果を十分に得られるようにするために、本実施形態では、上記の緩いルールが採用される。

なお、緩いルールが採用されると、第二の問題ケースが生じる確率が高くなってしまう可能性がある。そこで、第一の確率と第二の確率のどちらを優先するかに応じて、宛先名称判定処理での判定結果を採用するか否かが、切替えられても良い。この切替えは、例えば、社内端末２のユーザ別に、ユーザからの要求によって行われても良いし（つまり、ユーザが手動で設定しても良いし）、宛先正否判定システム３に予め設定されたポリシーに応じて自動で行われても良い（例えば、或る時間帯、メール本文の内容が特定の内容である等のケースでは第一の確率を低くすることよりも第二の確率を高くしないことが優先度が高い場合に、宛先名称判定処理での判定結果が非採用となっても良い）。宛先名称判定処理での判定結果を非採用とするとは、判定結果を無視することであっても良いし、宛先名称判定部３１３をターンオフにして宛先名称判定処理を行わないことであっても良い。

図５は、宛先ドメイン判定処理の詳細を説明する図である。図５を参照して、宛先ドメイン判定処理の流れを説明する。

宛先ドメイン判定部３１４は、対象メールのメールヘッダに設定された宛先データから、第一のドメイン文字列を抽出する（Ｓ２０１）。図５の例では、メールヘッダのＴＯに設定された宛先データには、第一のドメイン文字列として“a-comp.co.jp”が含まれている。また、メールヘッダのＣＣに設定された宛先データには、ドメイン文字列である“b-comp.co.jp”が含まれている。従って、本例の場合、第一のドメイン文字列として、“a-comp.co.jp”及び“b-comp.co.jp”の二つのドメイン文字列が抽出される。

一方で、宛先ドメイン判定部３１４は、対象メールのメール本文から、第二のドメイン文字列を抽出する。具体的には、宛先ドメイン判定部３１４は、以下のような処理を行う。

即ち、宛先ドメイン判定部３１４は、対象メールのメール本文に含まれている全てのメールアドレス（以下、「本文中メールアドレス」）を抽出する（Ｓ２０２）。本例では、本文中メールアドレスとして、“[email protected]”、“[email protected]”、“[email protected]”及び“[email protected]”の四つが抽出される（四つのうちの二つの本文中メールアドレスは重複しているため、図５には、三つの本文中メールアドレスを示している）。

次に、宛先ドメイン判定部３１４は、対象メールのメールヘッダのＦＲＯＭに設定されたデータ（以下、「送信元データ」）から、送信元のメールアドレスを抽出する（Ｓ２０３）。本例では、送信元のメールアドレスとして、“[email protected]”が抽出される。

次に、宛先ドメイン判定部３１４は、本文中メールアドレスのうちの送信元のメールアドレスとは異なるものを抽出する（Ｓ２０４）。本例では、送信元のメールアドレス“[email protected]”とは異なる本文中メールアドレス、即ち、“[email protected]”及び“[email protected]”が抽出される。

次に、宛先ドメイン判定部３１４は、Ｓ２０４で抽出されたメールアドレスの各々におけるアットマークよりも後の文字列を抽出する（Ｓ２０５）。このＳ２０５で抽出された文字列が、第二のドメイン文字列となる。本例の場合、第二のドメイン文字列として、“a-comp.co.jp”及び“b-comp.co.jp”の二つのドメイン文字列が得られる。

このように、本実施形態では、本文中メールアドレス（正確には、本文中メールアドレスから送信元のメールアドレスを除いたもの）のアットマークよりも後の文字列が、第二のドメイン文字列として採用されている。これは、例えば、対象メールが受信メールを引用した返信メールである場合、一般に、引用文中（特に、引用文に含まれる署名部分）及び／又は自動追加部分に相手方のメールアドレスが含まれていることが多いという実情に基づいている。なお、自動追加部分とは、メーラによって返信メールのメール本文に自動で追加される記載部分（図５では、“鈴木さん＜[email protected]＞ Wrote:”）である。

その後、宛先ドメイン判定部３１４は、Ｓ２０１で抽出された第一のドメイン文字列とＳ２０５で抽出された第二のドメイン文字列とを比較して、判定結果を決定する（Ｓ２０６、Ｓ２０７）。例えば、宛先ドメイン判定部３１４は、いずれの第一のドメイン文字列も、いずれかの第二のドメイン文字列と一致した場合に、宛先のドメインは正しいと判定することができる。つまり判定結果としてＯＫを出力することができる。言い換えると、宛先ドメイン判定部３１４は、少なくとも一つの第一のドメイン文字列が、いずれの第二のドメイン文字列のいずれとも一致しなかった場合に、宛先のドメインが誤っていると判定することができる。つまり判定結果としてＮＧを出力することができる。このようなルールによれば、本例では、第一及び第二のドメイン文字列は、いずれも“a-comp.co.jp”及び“b-comp.co.jp”であり、故に、いずれの第一のドメイン文字列も、いずれかの第二のドメイン文字列と一致する。このため、宛先のドメインは正しいと判定される。

以上が、宛先ドメイン判定処理の流れの説明である。

宛先ドメイン判定処理での判定結果がＯＫとなるためのルールは、宛先名称判定処理での判定結果がＯＫとなるためのルールよりも厳しいルールとなっている。具体的には、メール文中に含まれる第二のドメイン文字列を許可リストとし、第一のドメイン文字列のそれぞれがこの許可リスト中にあるいずれかの第二のドメイン文字列と一致する場合のみ、宛先ドメイン判定処理での判定結果がＯＫとされる。これにより、下記の条件（１）〜（３）の全てが成立すれば、上記の宛先ドメイン判定処理によって、第二の確率を高くしないようにしつつ、第一の確率を低くすることができる。
（１）対象メールが、或るメールに対する返信メールに対する更なる返信メールであること（すなわち、少なくとも一回、送信と返信のサイクルが行われており、対象メールが、その返信メールに対する返信メールであること）；
（２）返信の際に、双方が、相手のメールを全文引用していること（少なくとも、署名部分及び／又は自動追加部分を削除していないこと）；
（３）返信の際に、双方が、自分のメールアドレスを含んだ署名部分をメール本文中に含めていること（少なくとも、対象メールのメール本文が、送信元のメールアドレスを含んだ署名部分を有していること）。

なお、ドメイン文字列は、アットマークより後の全ての文字列でなくても良い。例えば、アットマークより後の文字列が長い場合には（例えば、単語数が所定数を超えている場合には）、ドメイン文字列としては、その文字列のうちの、先頭から最初に出現するドット“．”以降の文字列（ドメイン文字列又は第二のドメイン文字列が“section-a.a-comp.co.jp”であれば、“a-comp.co.jp”）が、ドメイン文字列として採用されても良い。

また、メール本文から抽出された複数のメールアドレスから送信元メールアドレスに一致するメールアドレスが必ずしも除外されなくても良い。

また、対象メールのメール本文全体からメールアドレスを抽出することに代えて、そのメール本文のうちの特定の部分（例えば、署名部分及び／又は自動追加部分）からメールアドレスが抽出されても良い。しかし、抽出範囲を上記実施形態のようにメール本文全体とした方が、メール本文のうちの特定の部分のみを抽出範囲とするよりも処理の負荷が低いため、高速な処理が期待できる。また、「特定の部分」とは、宛先の電子メールアドレスが含まれていると予想される部分であるが、必ずしも、いずれかの特定の部分に、宛先の電子メールアドレスが含まれているとは限らない。抽出範囲を上記実施形態のようにメール本文全体とすることにより、宛先の電子メールアドレスを抽出できる確率が高まることが期待できる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。

本発明の一実施形態に係るネットワークシステムの構成例を示す図である。 宛先正否判定システムの構成例を示す図である。 宛先正否判定処理の説明図である。 宛先名称判定処理の詳細を説明する図である。 宛先ドメイン判定処理の詳細を説明する図である。

符号の説明

１…ネットワークシステム、２…社内端末、３…宛先正否判定システム、４…メールサーバ、５…社外端末、１１…社内ネットワーク、１２…社外ネットワーク

Claims (7)

1. 入力された電子メールのメールヘッダから宛先の名称を示す第一の名称文字列を取得する第一の名称取得手段と、
   前記入力された電子メールのメール本文から宛先の名称を示す第二の名称文字列を取得する第二の名称取得手段と、
   前記第一の名称文字列と前記第二の名称文字列との比較である名称比較を行う名称比較手段と、
   前記名称比較の結果、及び、前記入力された電子メールの宛先を分類するための機械学習での判定結果のいずれかが、正しいとの判定結果であれば、前記入力された電子メールの宛先が正しいと判定する判定手段と
   を備える宛先正否判定システム。
2. 前記入力された電子メールのメールヘッダから宛先のドメインを示す第一のドメイン文字列を取得する第一のドメイン取得手段と、
   前記入力された電子メールのメール本文から宛先のドメインを示す第二のドメイン文字列を取得する第二のドメイン取得手段と、
   前記第一のドメイン文字列と前記第二のドメイン文字列との比較であるドメイン比較を行うドメイン比較手段と
   を備え、
   前記判定手段は、前記名称比較の結果、前記ドメイン比較の結果、及び、前記入力された電子メールの宛先を分類するための機械学習での判定結果のいずれかが、正しいとの判定結果であれば、前記入力された電子メールの宛先が正しいと判定する、
   請求項１記載の宛先正否判定システム。
3. 前記名称比較手段は、少なくとも一つの前記第一の名称文字列がいずれかの前記第二の名称文字列と一致していれば、前記名称比較の結果を、正しいとの判定結果にし、
   前記ドメイン比較手段は、前記第一のドメイン文字列のそれぞれが必ず前記第二のドメイン文字列のいずれかと一致する場合のみ、前記ドメイン比較の結果を正しいとの結果にする、
   請求項２記載の宛先正否判定システム。
4. 前記名称比較の結果を採用するか否かを切替える切替手段を更に備える、
   請求項２又は３記載の宛先正否判定システム。
5. 前記第二のドメイン取得手段は、前記メール本文全体から電子メールアドレスを抽出し、抽出された電子メールアドレスを基に、前記第二のドメイン文字列を取得する、
   請求項２乃至４のいずれかに記載の宛先正否判定システム。
6. 前記名称比較手段は、少なくとも一つの前記第一の名称文字列がいずれかの前記第二の名称文字列と一致していれば、前記名称比較の結果を、正しいとの判定結果にする、
   請求項１記載の宛先正否判定システム。
7. 複数の前記第一の名称文字列は、前記メールヘッダに含まれる表示名と、前記メールヘッダに含まれるメールアドレスにおけるアカウント名であり、
   前記第一及び第二の名称取得手段は、前記第一及び第二の名称文字列のうちローマ字表記となっていない文字列をローマ字表記に変換し、ローマ字表記変換後の第一及び第二の名称文字列における表記ゆれ対象の表記を、その表記ゆれ種類に対応した所定の統一表記に変換し、
   前記名称比較手段は、表記ゆれ対象の表記が統一表記に変換された後のローマ字表記の第一の名称文字列と第二の名称文字列とを比較する、
   請求項１乃至６のいずれかに記載の宛先正否判定システム。

Images