(57)【特許請求の範囲】
【請求項１】
送信すべき電子メールについて、ユニークなメールＩＤを採番し、前記電子メールのエンベロープ部に設定された送信元アドレスのローカル部文字列と前記メールＩＤとを所定のハッシュ関数へ入力してハッシュ文字列を取得し、前記電子メールのヘッダ部ではなくエンベロープ部の送信元アドレスのローカル部文字列に、前記メールＩＤおよび前記ハッシュ文字列を付加する第１の生成部と、
前記第１の生成部によりメールＩＤおよびハッシュ文字列が付加された電子メールを外部に送信する送信部と、
電子メールの配信エラーを通知するための電子メールであるエラー通知メールを外部から受信する受信部と、
受信されたエラー通知メールについて、そのエンベロープ部に設定された宛先アドレスのローカル部文字列から、メールＩＤおよび第１のハッシュ文字列を特定する特定部と、
前記宛先アドレスのローカル部文字列から前記特定部により特定されたメールＩＤおよび第１のハッシュ文字列を除いた残余文字列と、前記特定されたメールＩＤとを前記所定のハッシュ関数へ入力して第２のハッシュ文字列を取得する第２の生成部と、
受信されたエラー通知メールのうち、前記特定部により特定された第１のハッシュ文字列と、前記第２の生成部により取得された第２のハッシュ文字列とが合致するエラー通知メールを、自装置が送信した電子メールに対するエラー通知メールであり、かつ、所定のメンテナンス処理の対象とすべきエラー通知メールとして特定する識別データ検証部と、
を備えることを特徴とするメールサーバ。
【請求項２】
前記識別データ検証部は、前記自装置が送信した電子メールに対するエラー通知メールであり、かつ、所定のメンテナンス処理の対象とすべきエラー通知メールとして特定した電子メールについて、そのメールＩＤを所定の記憶装置へ格納し、別のエラー通知メールが受信された場合に、その第１のハッシュ文字列と第２のハッシュ文字列とが合致するときでも、そのメールＩＤが前記記憶装置に格納済みであれば、前記別のエラー通知メールを虚偽のエラー通知メールとして特定することを特徴とする請求項１に記載のメールサーバ。
【請求項３】
前記受信部において受信されたエラー通知メールについて、少なくともそのエンベロープ部の宛先アドレスを所定のログファイルに出力するログ出力部をさらに備え、
前記特定部は、前記ログファイルに出力されたエラー通知メールの宛先アドレスから、メールＩＤおよび第１のハッシュ文字列を特定することを試行し、
前記第２の生成部は、前記ログファイルに出力されたエラー通知メールのうち、前記特定部によりメールＩＤおよび第１のハッシュデータが特定されたエラー通知メールを対象として前記第２のハッシュ文字列を取得することを特徴とする請求項１または２に記載のメールサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理技術に関し、特に、電子メールのデータを処理するメールサーバに関する。
【背景技術】
【０００２】
ＩＴの発展に伴い、企業から顧客に対して多くの電子メールが送信されている。メール送信元の企業は、送信した電子メールが顧客に到達しないとき、システムをメンテナンスすることがあり、したがって、電子メールが顧客に到達したか否かに関心を持つことがある。以下の特許文献１では、電子メールの受信者から電子メールの送信者に電子メールの送信状態を通知させる技術が提案されている。
【特許文献１】特開２００２−２０７６７４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
多くの人々の端末がネットワークに接続されている現在、悪意のあるユーザが企業に対して不正なデータを送信することがある。例えば、このユーザは、電子メールの配信エラーを通知するためのエラー通知メールを擬装した虚偽のエラー通知メールを企業に送信することがある。企業のシステムでは、エラー通知メールに応じて、所定のメンテナンス処理が実行されることがあるため、虚偽のエラー通知メールにより、本来実行されるべきでないメンテナンス処理が実行されることがある。
【０００４】
本発明は、本発明者の上記着目に基づいて完成された発明であり、その主たる目的は、自システムにより送信された電子メールに対するエラー通知メールを特定する技術を提供することである。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明のある態様のメールサーバは、送信すべき電子メールについて、所定の規則にしたがって、自装置が送信した電子メールであることを識別するための識別データを生成する生成部と、識別データが付加された電子メールを外部に送信する送信部と、電子メールの配信エラーを通知するための電子メールであるエラー通知メールを外部から受信する受信部と、受信されたエラー通知メールのうち、そのデータに識別データが含まれるエラー通知メールを、自装置が送信した電子メールに対するエラー通知メールとして特定する特定部と、を備える。
【０００６】
所定の規則および識別データの態様に特に制限はなく、企業の経験や本メールサーバを備えるシステムでの実験により適切な態様が決定されてよい。例えば、所定のハッシュ関数にしたがって生成されるハッシュ値を含む識別データが設定されてもよく、所定のチェックサムやパリティのデータを含む識別データが設定されてもよい。
【０００７】
本発明の別の態様もまた、メールサーバである。このメールサーバは、送信すべき電子メールについて、所定の規則にしたがって、当該電子メールの少なくとも一部のデータから一意に定まる第１の識別データを生成する第１の生成部と、第１の識別データが付加された電子メールを外部に送信する送信部と、電子メールの配信エラーを通知するための電子メールであるエラー通知メールを外部から受信する受信部と、受信されたエラー通知メールのうち、そのデータに第１の識別データが含まれるエラー通知メールについて、規則にしたがって、当該エラー通知メールの少なくとも一部のデータから一意に定まる第２の識別データを生成する第２の生成部と、第１の識別データと第２の識別データとが合致するエラー通知メールを、自装置が送信した電子メールに対するエラー通知メールとして特定する識別データ検証部と、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、自システムにより送信された電子メールに対するエラー通知メールを高い精度で特定できる。
【発明を実施するための最良の形態】
【００１０】
本発明の実施の形態について、その構成を説明する前に、まず概要を説明する。
多くの顧客を抱える企業は、商品やサービスを顧客に通知するための電子メールを顧客端末に対して送信する。顧客の中には、企業に登録したメールアドレスを廃止した等の理由により、その電子メールを受信できない顧客も存在する。自社のメールサーバと直接通信するメールサーバにおいて、その顧客のメールアカウントが管理されているときには、ＳＭＴＰ（Simple Mail Transfer Protocol）通信時に、特定のリプライコードにより、電子メールの配信エラーが通知されることが多い。
【００１１】
しかし、一般的には、企業のメールサーバと、顧客のメールアカウントを管理するメールサーバとの間には、電子メールをリレーする別のメールサーバが介在することが多い。したがって、企業のメールサーバと直接通信するメールサーバとの間では電子メールの送信が正常に完了したときでも、以降のメールサーバにおいて、その電子メールの配信エラーが発生することがある。この場合、電子メールの配信エラーを検出したメールサーバは、企業のメールサーバに対して、配信エラーを通知するためのエラー通知メールを送信することで、電子メールの配信エラーを企業側に通知する。
【００１２】
企業のシステムは、メールサーバにおいて受信されたエラー通知メールに応じて、所定のメンテナンス処理を実行する。例えば、所定回数以上、エラー通知メールにより配信エラーが通知されたメールアドレスには、それ以降、電子メールを送信しないように設定することがある。また例えば、そのメールアドレスと対応づけられた顧客情報に基づき、電子メール以外の方法で顧客に情報が通知されることがある。
【００１３】
一方で、企業を混乱させる等の目的で、企業に対して不正なデータを送信する悪意のあるユーザ（以下、「悪意者」と呼ぶ。）が存在する。この悪意者は、実際には発生していない虚偽の配信エラーを通知するエラー通知メール（以下、「虚偽エラー通知メール」と呼ぶ。）を企業のメールサーバに対して送信する。
【００１４】
従来のメールサーバでは、自システムにより送信された電子メールに対するエラー通知メール（以下、「真のエラー通知メール」と呼ぶ。）と虚偽エラー通知メールとが分別されなかった。したがって、虚偽エラー通知メールによって、本来実行されるべきでないメンテナンス処理が実行されてしまうことがあった。例えば、企業からの電子メールを正常に受信している顧客について、その顧客への配信エラーを示す虚偽エラー通知メールにより、その顧客に電子メールが送信されなくなることがあった。
【００１５】
本発明の実施の形態では、企業から送信する電子メールについて、その企業から送信された電子メールであることを識別するための識別データを生成して、その識別データが付加された電子メールを外部のメールサーバに送信するメールシステムを提案する。このメールシステムは、受信したエラー通知メールのうち、正常な識別データが含まれるエラー通知メールを、真のエラー通知メールとして特定する。言い換えれば、受信されたエラー通知メールから虚偽エラー通知メールを排除して、所定のメンテナンス処理の対象となる真のエラー通知メールを特定する。
【００１６】
図１は、本発明の実施の形態であるメールシステムの構成を示す。
メールシステム１０００は、証券会社において電子メールの送受信に関するサービスを提供するシステムである。メールシステム１０００は、自社ＭＴＡ１００と、社員ＰＣ１１０と、メンテナンス処理装置１２０とを備える。同図の通信網２００は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット等、公知のネットワークを制限無く含む。以下、厳密には「・・・メールのデータ」を意味する場合も、単に「・・・メール」と表記することとする。
【００１７】
社員ＰＣ１１０は、ＭＵＡ（Mail User Agent）ソフトウェアがインストールされた一般的なメールクライアントであり、証券会社の社員により操作される。社員ＰＣ１１０は、証券会社の商品およびサービスを顧客に通知するために、それらの情報が記載された電子メール（以下、「ニュースメール」と呼ぶ。）を自社ＭＴＡ１００に送信する。メンテナンス処理装置１２０は、自社ＭＴＡ１００において真のエラー通知メールとして特定されたエラー通知メールを取得して、所定のメンテナンス処理を実行する。
【００１８】
自社ＭＴＡ１００は、ＭＴＡ（Message Transfer Agent）ソフトウェアがインストールされたメールサーバ（以下、単に「ＭＴＡ」と呼ぶ。）である。自社ＭＴＡ１００は、上述の識別データが付加されたニュースメールを、通信網２００を介して、外部のＭＴＡに対して送信する。また、自社ＭＴＡ１００は、通信網２００を介して、外部からエラー通知メールを受信する。自社ＭＴＡ１００は、エラー通知メールの識別データを検査して、正常な識別データが含まれるエラー通知メールを真のエラー通知メールとして特定し、メンテナンス処理装置１２０に送信する。
【００１９】
図２は、図１の自社ＭＴＡ１００の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところであり、これらのいずれかに限定されるものではない。
【００２０】
また、本明細書の各装置においては、当該装置を効率よく利用するための機能および環境を提供して当該装置の全体を統括的に制御するオペレーティングシステム（以下、「ＯＳ」と呼ぶ。）が実行されてもよい。この場合、かかるＯＳによってブロック図の各機能ブロックが動作させられることにより、複数のソフトウェアが実行される。
【００２１】
自社ＭＴＡ１００は、要求受付部１０と、第１生成部１２と、メール送信部１４と、メール受信部１６と、ログ出力部１８と、特定部２０と、第２生成部２２と、識別データ検証部２４と、エラー通知部２６とを有する。要求受付部１０は、社員ＰＣ１１０とＳＭＴＰ通信を行って、ニュースメールの送信要求を受け付ける。
【００２２】
第１生成部１２は、送信すべきニュースメールについて、そのエンベロープ部に設定された差出人を示す文字列（以下、「エンベロープＦｒｏｍ」と呼ぶ。）を特定し、エンベロープＦｒｏｍのローカル部に設定された文字列（以下、「ローカル文字列」と呼ぶ。）を特定する。エンベロープＦｒｏｍには送信元を示すメールアドレスが設定されるため、メールアドレスにおける「＠」より前の文字列がローカル文字列として特定される。
【００２３】
続いて、第１生成部１２は、送信すべきニュースメールを自システムにおいて一意に特定するためのメールＩＤを採番する。第１生成部１２は、エンベロープＦｒｏｍのローカル文字列およびメールＩＤを所定のハッシュ関数に入力して、このハッシュ関数の出力であるハッシュ値を示す文字列（以下、「第１ハッシュ文字列」と呼ぶ。）を生成する。このハッシュ関数は、特定の入力に対して一意の結果を出力する関数であればよく、公知のハッシュアルゴリズムが実装されたものでもよい。
【００２４】
さらに、第１生成部１２は、メールＩＤおよび第１ハッシュ文字列をエンベロープＦｒｏｍに元々設定されていたローカル文字列の後ろに付加する。なお、所定のデリミタ文字も付加して、元々のローカル文字列、メールＩＤおよび第１ハッシュ文字列を区分けしてもよい。メール送信部１４は、外部のＭＴＡとＳＭＴＰ通信を行って、メールＩＤと第１ハッシュ文字列とが付加されたニュースメールを外部のＭＴＡに送信する。
【００２５】
メール受信部１６は、外部の装置とＳＭＴＰ通信を行って、エラー通知メールを受信し、そのエラー通知メールを図示しない記憶装置に記録する。このエラー通知メールのエンベロープ部に設定された宛先を示す文字列（以下、「エンベロープＴｏ」と呼ぶ。）には、典型的には、配信エラーが発生したニュースメールのエンベロープＦｒｏｍが設定されている。このようなエンベロープＴｏの設定は、ＲＦＣ（Request For Comment）２８２１に規定されており、外部のＭＴＡにより実施される。
【００２６】
ログ出力部１８は、エラー通知メールのエンベロープＴｏを所定のログファイルに出力する。ログ出力部１８は、メール受信部１６と外部の装置とのＳＭＴＰ通信中に、ＲＣＰＴコマンドにより外部の装置からエンベロープＴｏが通知されたとき、そのエンベロープＴｏをログファイルに出力してもよい。
【００２７】
特定部２０は、ログファイルに出力されたエンベロープＴｏについて、メールＩＤと、第１ハッシュ文字列と、メールＩＤおよび第１ハッシュ文字列、必要であればデリミタ文字も排除された残余のローカル文字列を特定する。例えば、特定のデリミタ文字で区分けされた領域のデータをそれぞれ取得することで、メールＩＤおよび第１ハッシュ文字列を特定してもよい。また、メールＩＤおよび第１ハッシュ文字列が固定長である場合には、その長さに基づき、エンベロープＴｏの所定の位置からメールＩＤおよび第１ハッシュ文字列を抽出してもよい。最終的に、特定部２０は、メールＩＤおよび第１ハッシュ文字列がローカル文字列に存在するエンベロープＴｏを特定する。
【００２８】
第２生成部２２は、メールＩＤおよび第１ハッシュ文字列がローカル文字列に存在するエンベロープＴｏについて、特定部２０において特定された残余のローカル文字列と、メールＩＤとを所定のハッシュ関数に入力する。第２生成部２２は、ハッシュ関数の出力であるハッシュ値を示す文字列（以下、「第２のハッシュ文字列」と呼ぶ。）を生成する。このハッシュ関数は、第１生成部１２において使用されるハッシュ関数であり、入力が同じであれば、第１生成部１２におけるハッシュ値と同じハッシュ値が出力される。
【００２９】
識別データ検証部２４は、メールＩＤおよび第１ハッシュ文字列がローカル文字列に存在するエンベロープＴｏのうち、第１ハッシュ文字列と第２のハッシュ文字列とが合致するエンベロープＴｏを、真のエラー通知メールのエンベロープＴｏとして特定する。エラー通知部２６は、図示しない記憶装置を参照して、真のエラー通知メールのエンベロープＴｏをキーとしてエラー通知メールを取得し、そのエラー通知メールをメンテナンス処理装置１２０に送信する。
【００３０】
以上の構成による動作を以下説明する。
図３は、図１のメールシステム１０００と他システムとの連携を示す。同図の１次ＭＴＡ３００、第１の２次ＭＴＡ４００、第２の２次ＭＴＡ５００は、いずれもＭＴＡである。また、第１の顧客ＰＣ４１０、第２の顧客ＰＣ５１０、悪意者ＰＣ６００は、ＭＵＡがインストールされた一般的なメールクライアントである。また、同図の実線の矢印は、メールシステム１０００から送信されるニュースメールに基づくデータの流れを示している。また、破線の矢印はニュースメールの配信エラーに基づくデータの流れを示している。
【００３１】
社員ＰＣ１１０は、第１の顧客および第２の顧客宛のニュースメールを自社ＭＴＡ１００に送信する。社員ＰＣ１１０から送信されるニュースメールのエンベロープＴｏには、第１の顧客および第２の顧客のメールアドレスがそれぞれ設定されている。一方で、エンベロープＦｒｏｍには、社員のメールアドレス、ここでは「ａｃｂｇ＠ｈｏｇｅ．ｃｏｍ」が設定されている。
【００３２】
自社ＭＴＡ１００の要求受付部１０は、第１の顧客に送信すべきニュースメールと、第２の顧客に送信すべきニュースメールとを社員ＰＣ１１０から受信する。自社ＭＴＡ１００の第１生成部１２は、各ニュースメールにおけるエンベロープＦｒｏｍを変換する。
【００３３】
図４（ａ）（ｂ）は、エンベロープＦｒｏｍの変換の説明図である。図４の（ａ）および図４の（ｂ）それぞれの上段は、第１の顧客に送信すべきニュースメールおよび第２の顧客に送信すべきニュースメールについて、変換前のエンベロープＦｒｏｍが示されている。ここでは、どちらも上述した社員のメールアドレスが示されている。図４の（ａ）および図４の（ｂ）それぞれの下段には、メールＩＤおよび第１ハッシュ文字列が付加された変換後のエンベロープＦｒｏｍが示されている。
【００３４】
第１生成部１２は、第１の顧客に送信すべきニュースメールには、メールＩＤ「０１」を採番し、エンベロープＦｒｏｍのローカル文字列「ａｃｂｇ」およびメールＩＤ「０１」をハッシュ関数に入力して第１ハッシュ文字列を生成する。ここでは、簡明な説明のため、ローカル文字列の１文字目、メールＩＤの１文字目、ローカル文字列の２文字目、メールＩＤの２文字目を順に組み合わせて、４文字の第１ハッシュ文字列が生成されることとする。したがって、第１生成部１２は、ハッシュ値「ａ０ｃ１」を生成する。第１生成部１２は、元々のローカル文字列「ａｃｂｇ」にデリミタ文字「−」で区分けされたメールＩＤ、ハッシュ値を付加する。その結果、図４（ａ）では、変換後のエンベロープＦｒｏｍとして、「ａｃｂｇ−０１−ａ０ｃ１＠ｈｏｇｅ．ｃｏｍ」が設定されている。
【００３５】
また、第１生成部１２は、第２の顧客に送信すべきニュースメールには、メールＩＤ「０２」を採番し、エンベロープＦｒｏｍのローカル文字列「ａｃｂｇ」およびメールＩＤ「０２」をハッシュ関数に入力して第１ハッシュ文字列を生成する。その結果、図４（ｂ）では、変換後のエンベロープＦｒｏｍとして、「ａｃｂｇ−０２−ａ０ｃ２＠ｈｏｇｅ．ｃｏｍ」が設定されている。図３に戻る。
【００３６】
自社ＭＴＡ１００のメール送信部１４は、メールＩＤおよび第１ハッシュ文字列が付加されたニュースメールを１次ＭＴＡ３００に送信する。１次ＭＴＡ３００への送信中に、１次ＭＴＡ３００において配信エラーが検出されたときには、１次ＭＴＡ３００からエラーを示すリプライコードが返され、自社ＭＴＡ１００はその配信エラーを検出できる。
【００３７】
１次ＭＴＡ３００は、自社ＭＴＡ１００から受信した電子メールを、そのエンベロープＴｏの指定に応じて、第１の２次ＭＴＡ４００または第２の２次ＭＴＡ５００にリレーする。第１の２次ＭＴＡ４００は、第１の顧客宛の電子メールを第１の顧客のメールアカウントに対応づけられたメールボックスに格納し、第１の顧客ＰＣ４１０の要求に応じて、その電子メールを第１の顧客ＰＣ４１０に送信する。また、第２の２次ＭＴＡ５００は、第２の顧客宛の電子メールを第２の顧客のメールアカウントに対応づけられたメールボックスに格納し、第２の顧客ＰＣ５１０の要求に応じて、その電子メールを第１の顧客ＰＣ４１０に送信する。
【００３８】
自社ＭＴＡ１００とのＳＭＴＰ通信を完了した以降の１次ＭＴＡ３００、第１の２次ＭＴＡ４００、第２の２次ＭＴＡ５００においてメールデータの配信エラーが発生したとき、これらのＭＴＡは自社ＭＴＡ１００に対して真のエラー通知メールを送信する。配信エラーとしては、例えば、ＤＮＳ（Domain Name System）による名前解決処理のエラーや、メールリレー時のエラー、メールボックスへのデータ格納時のエラーがある。
【００３９】
一方で、悪意者ＰＣ６００は、自社ＭＴＡ１００に対して虚偽エラー通知メールを送信する。虚偽エラー通知メールのエンベロープＴｏでは、典型的には、第１ハッシュ文字列が設定されず、または、悪意者ＰＣ６００において独自に生成された文字列が第１ハッシュ文字列の領域に設定されている。なお、図３では、悪意者ＰＣ６００が自社ＭＴＡ１００と直接接続されているが、１以上の他のＭＴＡを介して接続されてもよい。
【００４０】
自社ＭＴＡ１００のメール受信部１６は、真のエラー通知メールおよび虚偽エラー通知メールが混在するエラー通知メールを、１次ＭＴＡ３００、第１の２次ＭＴＡ４００、第２の２次ＭＴＡ５００、または悪意者ＰＣ６００から受信する。メール受信部１６は、エラー通知メールを図示しない記憶装置に記録する。ログ出力部１８は、エラー通知メールにおけるエンベロープＴｏをログファイルに出力する。図５は、ログファイルに記録されたデータを示す。同図のログファイル７００には、ログ出力部１８により記録されたエンベロープＴｏ７０２からエンベロープＴｏ７０８が含まれている。
【００４１】
自社ＭＴＡ１００の特定部２０は、ログファイル７００に出力されたエンベロープＴｏの要素を特定する。すなわち、エンベロープＴｏのうち、最も後ろのデリミタ文字から「＠」の前までの文字列を第１ハッシュ文字列として特定する。また、後ろから２番目のデリミタ文字から最も後ろのデリミタ文字までの文字列をメールＩＤとして、また、後ろから２番目のデリミタ文字より前の文字列を残余文字列として特定する。図５のエンベロープＴｏ７０２については、デリミタ文字が存在しないため、いずれの要素も特定されない。
【００４２】
図６は、図５のエンベロープＴｏの各要素を示す。特定部２０は、図５のエンベロープＴｏ７０２からエンベロープＴｏ７０８について、図６の残余文字列欄、メールＩＤ欄、第１ハッシュ文字列欄で示される各データを特定する。特定部２０は、図６のエンベロープＴｏのうち、メールＩＤおよび第１ハッシュ文字列が存在するエンベロープＴｏ７０４、エンベロープＴｏ７０６、およびエンベロープＴｏ７０８を以降の処理対象として特定する。
【００４３】
自社ＭＴＡ１００の第２生成部２２は、メールＩＤおよび第１ハッシュ文字列が存在するエンベロープＴｏについての第２ハッシュ文字列を生成する。第２ハッシュ文字列の生成ロジックは、第１ハッシュ文字列と同様である。図６の第２ハッシュ文字列欄に、エンベロープＴｏ７０４、エンベロープＴｏ７０６、およびエンベロープＴｏ７０８について生成された第２ハッシュ文字列が示されている。
【００４４】
自社ＭＴＡ１００の識別データ検証部２４は、第１ハッシュ文字列と第２ハッシュ文字列とを文字列比較して、第１ハッシュ文字列と第２ハッシュ文字列とが合致するエンベロープＴｏを、真のエラー通知メールのエンベロープＴｏであると特定する。すなわち、エンベロープＴｏ７０４およびエンベロープＴｏ７０６を特定する。
【００４５】
自社ＭＴＡ１００のエラー通知部２６は、記憶装置を参照して、エンベロープＴｏ７０４およびエンベロープＴｏ７０６にそれぞれ対応づけられたエラー通知メールをメンテナンス処理装置１２０に送信する。メンテナンス処理装置１２０は、自社ＭＴＡ１００から送信されたエラー通知メールにしたがって、所定のメンテナンス処理を実行する。
【００４６】
メールシステム１０００によれば、受信されたエラー通知メールのうち、虚偽エラー通知メールを排除して、自システムが送信した電子メールに対するエラー通知メールを高い精度で特定できる。これにより、虚偽のエラー通知メールにより、本来不要のメンテナンス処理が行われなくなり、企業および顧客に不利益が生ずる可能性を低減できる。
【００４７】
また、メールシステム１０００によれば、所定のハッシュ関数により生成されたハッシュ値が識別データとして電子メールに付加される。悪意者は、この識別データが付加されていることにそもそも気づきにくく、仮に識別データの存在に気づいたとしても、ハッシュアルゴリズムを特定する困難性から、虚偽エラー通知メールの送信を諦める可能性が高い。また、公知のハッシュアルゴリズムが使用される場合でも、ハッシュ値の生成に必要なパラメータは企業が独自に設定できるため、真のエラー通知メールとして判断される虚偽エラー通知メールを悪意者が作成することは困難である。
【００４８】
さらに、メールシステム１０００によれば、送信すべき電子メールについて、そのエンベロープＦｒｏｍに識別データを付加することで、エラー通知メールのエンベロープＴｏにその識別データが含まれる。ＭＴＡのログに少なくとも受信メールのエンベロープＴｏが出力されるように設定することで、ログファイルの参照により、言い換えればエラー通知メールそのものを参照することなく、真のエラー通知メールを特定できる。ログファイルへのエンベロープＴｏの出力は、標準的なＭＴＡソフトウェア、例えばｑｍａｉｌでは標準提供される機能であるため、システム開発のコストが削減される。また、エラー通知メールそのものの参照が不要であるため、特定処理を迅速にでき、また、特定処理に必要なハードウェアリソースを低減できる。
【００４９】
例えば、多くの顧客を抱える企業の中には、メーリングリスト等を利用して、一度に５０万人の顧客にニュースメールを送信する企業もある。虚偽エラー通知メールも含め、このうちの５％の顧客に関してエラー通知メールが受信されたとすると、その件数は２万５千件となる。１件あたりのデータ量が１０ＫＢとすると、エラー通知メールそのものを参照した場合、２５０ＭＢのデータを参照する必要がある。一方で、ログファイルに出力される１件あたりのデータ量は１００Ｂ程度であり、ログファイルを参照する場合には２．５ＭＢ、すなわち１００分の１のデータを参照すればよい。また、複数のエラー通知メールへのファイルアクセスが発生しない点もメリットである。
【００５０】
さらにまた、メールシステム１０００によれば、エンベロープＦｒｏｍのローカル文字列に識別データが付加される。電子メールのエンベロープ部はＭＴＡによるメール送信時に参照されるものであり、宛先のユーザがメールを確認する際には表示されないため、ユーザの混乱を招くことはない。また、エラー通知メールにおけるエンベロープＴｏのローカル文字列に識別データが含まれる。しかし、自社ＭＴＡ１００へのエラー通知メールの配信は、エンベロープＴｏのドメイン部のデータに基づくため、通常の電子メール配信の仕組みをそのまま利用できる。
【００５１】
なお、ニュースメールの配信エラーとは関係なく、外部から送信されたその他のメールと、エラー通知メールとを区別する必要はない。その他のメールには、典型的には、ニュースメールとは無関係に外部から送信されたメールと、ニュースメールに対する返信メールが含まれる。ニュースメールとは無関係に外部から送信されたメールには、メールＩＤおよび第１ハッシュ文字列は存在せず、存在した場合でもハッシュアルゴリズムが異なるため第２ハッシュ文字列と合致せず、真のエラー通知メールとして特定されない。
【００５２】
また、ニュースメールに対する返信メールのエンベロープＴｏには、ユーザ端末で受信されたニュースメールに設定されていたエンベロープＦｒｏｍは設定されない。典型的には、ユーザ端末で受信されたニュースメールのヘッダ部に設定された差出人データがユーザ端末のＭＵＡにより設定される。したがって、この場合もメールＩＤおよび第１ハッシュ文字列は存在せず、真のエラー通知メールとして特定されない。すなわち、自社ＭＴＡ１００は、真のエラー通知メール、虚偽エラー通知メール、その他のメールを区別せずに受信して、真のエラー通知メールを精度よく特定できる。
【００５３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００５５】
自社ＭＴＡ１００の識別データ検証部２４は、真のエラー通知メールのエンベロープＴｏであると特定したエンベロープＴｏについて、そのメールＩＤを図示しない記憶装置に記録してもよい。この場合、識別データ検証部２４は、真のエラー通知メールのエンベロープＴｏを特定する条件として、第１ハッシュ文字列と第２ハッシュ文字列とが合致し、かつ、その記憶装置にメールＩＤが記録されていないことを条件とする。これにより、悪意者がネットワークを流れるパケットをモニタして、真のエラー通知メールと全く同じエンベロープＴｏを有する虚偽エラー通知メールを送信した場合であっても、その虚偽エラー通知メールを排除できる。言い換えれば、真のエラー通知メールの特定精度をさらに向上できる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施の形態であるメールシステムの構成を示す図である。
【図２】図１の自社ＭＴＡの機能構成を示すブロック図である。
【図３】図１のメールシステムと他システムとの連携を示す図である。
【図４】図４（ａ）（ｂ）はエンベロープＦｒｏｍの変換の説明図である。
【図５】ログファイルに記録されたデータを示す図である。
【図６】図５のエンベロープＴｏの各要素を示す図である。
【符号の説明】
【００５７】
１０  要求受付部、  １２  第１生成部、  １４  メール送信部、  １６  メール受信部、  １８  ログ出力部、  ２０  特定部、  ２２  第２生成部、  ２４  識別データ検証部、  ２６  エラー通知部、  １００  自社ＭＴＡ、  １１０  社員ＰＣ、  １２０  メンテナンス処理装置、  ２００  通信網、  ３００  １次ＭＴＡ、  ４００  第１の２次ＭＴＡ、  ４１０  第１の顧客ＰＣ、  ５００  第２の２次ＭＴＡ、  ５１０  第２の顧客ＰＣ、  ６００  悪意者ＰＣ、  ７００  ログファイル、  １０００  メールシステム。
【図１】
0005244453.tif 000002
【図２】
0005244453.tif 000003
【図３】
0005244453.tif 000004
【図４】
0005244453.tif 000005
【図５】
0005244453.tif 000006
【図６】
0005244453.tif 000007