特許文献1〜4に記載の技術は受信した電子メールがエラーメールか否かを判断している。このエラーメールは、送信先電子メールアドレスによって自ドメイン内のメールボックスが送信先として設定された電子メールを受け取ったメールサーバ(受信側メールサーバ)が、受け取った電子メールを何らかの理由(例えば指定されたメールボックスが存在しなかったり、メールサーバに一時的な不調が生じていた等)で送信先のメールボックスに格納できなかった場合に、受信側のメールサーバによって自動的に送信される電子メールである。このため、任意の送信先へ電子メールを送信した後に、当該電子メールに設定した送信元電子メールアドレスを送信先とする電子メールを受信した場合に、上記技術を適用して受信メールがエラーメールか否かを判定するようにすれば、先に送信した電子メールの不達を検知することは原理的には可能である。
しかし、特許文献1〜3に記載されているエラーメールの判定条件は、IETF(Internet Engineering Task Force) の公式文書であるRFC(Request for Comments:インターネットに関する技術情報や仕様、運用規則などを定めた文書)の規約に準拠した判定条件であるのに対し、本願発明者等は、インターネット上に存在する膨大な数のメールサーバの中には、上記のRFCの規約に準拠しないエラーメールを送信するメールサーバが多数存在していることを確認しており、上記の判定条件では、実際にはエラーメールであるにも拘わらずエラーメールと判定されない電子メール(すなわち不達を検知できないケース)が多数発生する可能性がある、という問題がある。
また、特許文献4に記載にされているエラーメールの判定条件は、エラーメールとして送信された受信メールデータのヘッダ部の[From:]フィールドには、メールサーバによって"DEAMON","mailer","DELIVERY","SYSTEM","POST MASTER"等の特定文字列が設定されることが多いという経験則に基づき、これらの文字列を文字列リストテーブルに登録して照合に用いているが、多種多様なメールサーバがエラーメールの上記のフィールドに設定する文字列を全て認識してテーブルに登録することは困難であり、特許文献4に記載の技術を適用した場合にも、実際にはエラーメールであるにも拘わらずエラーメールと判定されない電子メールが多数発生する可能性がある。また、仮に、多種多様なメールサーバがエラーメールの上記のフィールドに設定する文字列を全て認識できたとしても、エラーメールの上記のフィールドに新たな文字列を設定するメールサーバが出現する可能性を考慮すると、エラーメールの判定精度維持のために文字列リストテーブルの定期的なメインテナンスが必要になる、という問題もある。
本発明は上記事実を考慮して成されたもので、送信した電子メールの不達を簡単かつ高精度に判定できるメール不達判定装置及びメール不達判定プログラムを得ることが目的である。
RFCの規約によれば、メールサーバから送信されるエラーメールはマルチパート構造で、"Content-Type:message/delivery-status"の文字列の後にエラーコードが記述されることになっている。これを確認するため、本願発明者等は、インターネット上に存在している膨大な数のメールサーバから、無作為に800を超える数のメールサーバを選択し、選択した個々のメールサーバに対し、個々のメールサーバからエラーメールが送信されるように送信先メールアドレスを設定した電子メールを各々送信し、送信した電子メールに対して個々のメールサーバから送信されたエラーメールの内容を解析する検討を行った。その結果、多くのメールサーバはRFCの規約に準拠したエラーメールを送信するものの、先にも述べたように、RFCの規約に準拠しないエラーメール、具体的には、"Content-Type:message/delivery-status"の文字列を含まないエラーメールを送信するメールサーバも多数存在していることを確認した。
また本願発明者等は、RFCの規約に準拠しないエラーメール("Content-Type:message/delivery-status"の文字列を含まないエラーメール)を送信するメールサーバから送信されたエラーメールに対して内容を更に解析し、共通する特徴を探し出す検討を行った。その結果、本願発明者等は上記のエラーメールから幾つかの共通する特徴を見出したが、そのうち、テキスト形式で本文が記述された電子メールをメールサーバへ送信した場合、メールサーバから送信されるエラーメールに含まれる本文がテキスト形式から変更されないという特徴(利用者が返信の電子メールを作成して送信した場合は本文がテキスト形式からHTML形式等の他の形式へ変更される可能性がある)と、メールサーバから送信されるエラーメールには、メールサーバへ送信した電子メールの情報が含まれているという特徴は、殆どのエラーメールに共通する特徴であり、かつ、受信した電子メールが上記の2つの特徴を備えているか否かの判定には、特許文献4に記載の技術における[From:]フィールドの判定のように、テーブルに登録するための文字列の収集や定期的なテーブルの更新等の煩雑な作業又は処理も不要であることに想到した。
上記に基づき請求項1記載の発明に係るメール不達判定装置は、シングルパート構造で本文がテキスト形式で記述された所定の電子メールを、本文に所定の識別情報を付加し、任意の電子メールアドレスを送信先として送信すると共に、前記所定の電子メールの情報の一部として、前記所定の識別情報、送信日時及び送信先の電子メールアドレスを記憶手段に各々記憶させるメール送信手段と、前記メール送信手段によって送信された前記所定の電子メールに設定された送信元電子メールアドレスを送信先とする電子メールが受信された場合に、受信された電子メールがマルチパート構造か否か判定する第1判定手段と、前記第1判定手段により前記受信された電子メールがマルチパート構造と判定された場合に、前記受信された電子メールに文字列"message/delivery-status"が含まれているか否かを判定する第2判定手段と、前記第2判定手段により前記受信された電子メールに文字列"message/delivery-status"が含まれていないと判定された場合に、前記受信された電子メールの情報に含まれる本文がテキスト形式から変更されていないか否かを判定する第3判定手段と、前記第3判定手段により前記本文がテキスト形式から変更されていないと判定された場合に、前記受信された電子メールの情報のうち元の電子メールの情報が設定されている部分に、前記記憶手段に記憶されている前記所定の識別情報、送信日時及び送信先の電子メールアドレスが全て含まれているか否かを判定することで、前記受信された電子メールに対応する前記所定の電子メールの情報が含まれているか否かを判定する第4判定手段と、前記第1判定手段により、前記受信された電子メールがマルチパート構造と判定され、かつ前記第2判定手段により、前記受信された電子メールに文字列"message/delivery-status"が含まれていないと判定され、かつ前記第3判定手段により、前記本文がテキスト形式から変更されていないと判定され、かつ前記第4判定手段により、前記受信された電子メールの情報に、前記受信された電子メールに対応する前記所定の電子メールの情報が含まれていると判定された場合に、前記受信された電子メールに対応する所定の電子メールが送信先に届かなかったとの判定結果を出力する出力手段と、を含んで構成されている。
請求項1記載の発明では、メール送信手段により、シングルパート構造で本文がテキスト形式で記述された所定の電子メールが、本文に所定の識別情報が付加され、任意の電子メールアドレスを送信先として送信されると共に、所定の電子メールの情報の一部として、所定の識別情報、送信日時及び送信先の電子メールアドレスが記憶手段に各々記憶される。ここで、所定の電子メールに設定された送信元電子メールアドレスを送信先とする電子メールが受信された場合に、第1判定手段は、受信された電子メールがマルチパート構造か否か判定し、第1判定手段により、受信された電子メールがマルチパート構造と判定された場合に、第2判定手段は、受信された電子メールに文字列"message/delivery-status"が含まれているか否かを判定する。このように、第1判定手段及び第2判定手段は、受信された電子メールがRFCの規約に準拠したエラーメールの特徴を備えているか否かを判定する。
また、第2判定手段により、受信された電子メールに文字列"message/delivery-status"が含まれていないと判定された場合に、第3判定手段は、受信された電子メールの情報に含まれる本文がテキスト形式から変更されていないか否かを判定し、第3判定手段により、受信された電子メールの情報に含まれる本文がテキスト形式から変更されていないと判定された場合に、第4判定手段は、受信された電子メールの情報のうち元の電子メールの情報が設定されている部分に、記憶手段に記憶されている所定の識別情報、送信日時及び送信先の電子メールアドレスが全て含まれているか否かを判定することで、受信された電子メールに対応する所定の電子メールの情報が含まれているか否かを判定する。このように、第3判定手段及び第4判定手段は、受信された電子メールがRFCの規約に準拠したエラーメールの特徴を一部備えていない(文字列"message/delivery-status"が含まれていない)場合に、本願発明者等が見出したエラーメールの別の特徴を備えているか否かを判定する。
そして、請求項1記載の発明では、第1判定手段により、受信された電子メールがマルチパート構造と判定され、かつ第2判定手段により、受信された電子メールに文字列"message/delivery-status"が含まれていないと判定され、かつ第3判定手段により、本文がテキスト形式から変更されていないと判定され、かつ第4判定手段により、受信された電子メールの情報に、受信された電子メールに対応する所定の電子メールの情報が含まれていると判定された場合に、出力手段により、受信された電子メールに対応する所定の電子メールが送信先に届かなかったとの判定結果を出力する。前述のように、第3判定手段及び第4判定手段が判定している特徴は、殆どのエラーメールに共通する特徴であり、判定精度が高い。また、第3判定手段及び第4判定手段による判定は、テーブルに登録するための文字列の収集や定期的なテーブルの更新等の煩雑な作業又は処理も不要である。従って、請求項1記載の発明によれば、送信した電子メールの不達を簡単かつ高精度に判定することができる。
ところで、請求項1記載の発明において、例えば請求項2に記載したように、出力手段は、第2判定手段により、受信された電子メールに文字列"message/delivery-status"が含まれていると判定された場合に、受信された電子メールに対応する所定の電子メールが送信先に届かなかったとの判定結果を出力するように構成することが好ましい。受信された電子メールに対して第2判定手段が上記のように判定した場合、受信した電子メールはRFCの規約に準拠したエラーメールであり、受信された電子メールに対応する所定の電子メールが送信先に届いていないと判断できる。これにより、受信された電子メールがRFCの規約に準拠したエラーメールであることに基づいて送信した電子メールが不達と判定できる場合に、これを判定結果として出力することができる。
また、電子メールの情報に含まれる本文がテキスト形式からHTML形式へ変更された場合、電子メールの情報には文字列"text/html"が付加される。このため、請求項1記載の発明において、第3判定手段による判定は、具体的には、例えば請求項3に記載したように、受信された電子メールの情報に文字列"text/html"が含まれているか否かを検索し、検索によって文字列"text/html"が抽出されなかった場合に、受信された電子メールの情報に含まれる本文はテキスト形式から変更されていないと判定することで行うことができる。
ところで、受信された電子メールにはファイルが添付されている可能性もあるが、メールサーバによってエラーメールにファイルが追加添付されることはまず無いことが本願発明者等によって確認されている。これを考慮すると、請求項1記載の発明において、例えば請求項4に記載したように、第3判定手段は、受信された電子メールにファイルが添付されているか否かも判定し、第4判定手段は、第3判定手段により、受信された電子メールの情報に含まれる本文がテキスト形式から変更されていないと判定され、かつ受信された電子メールにファイルが添付されていないと判定された場合に、前記所定の電子メールの情報が含まれているか否かの判定を行うように構成することが好ましい。これにより、送信した電子メールの不達についての判定精度を更に向上させることができる。
また、請求項1記載の発明において、第4判定手段による判定は、具体的には、例えば請求項5に記載したように、メール送信手段を、所定の電子メールの本文に所定の識別情報(この識別情報としては、例えば電子メールの送信順に個々の電子メールに付与した通番や、個々の電子メール毎に相違する情報をハッシュ関数に入力して演算することで得られたハッシュ値等を適用することができる)を付加して送信すると共に、所定の電子メールの情報の一部として、所定の識別情報、送信日時及び送信先の電子メールアドレスを対応付けて記憶手段に記憶させるように構成し、第4判定手段を、受信された電子メールの情報のうち元の電子メールの情報が設定されている部分に、記憶手段に対応付けて記憶されている所定の識別情報、送信日時及び送信先の電子メールアドレスが全て含まれているか否かを判定することで、受信された電子メールに対応する所定の電子メールの判定、及び、受信された電子メールの情報に対応する所定の電子メールの情報が含まれているか否かの判定を行うように構成することが好ましい。
請求項6記載の発明に係るメール不達判定プログラムは、コンピュータを、シングルパート構造で本文がテキスト形式で記述された所定の電子メールを、本文に所定の識別情報を付加し、任意の電子メールアドレスを送信先として送信すると共に、前記所定の電子メールの情報の一部として、前記所定の識別情報、送信日時及び送信先の電子メールアドレスを記憶手段に各々記憶させるメール送信手段、前記メール送信手段によって送信された前記所定の電子メールに設定された送信元電子メールアドレスを送信先とする電子メールが受信された場合に、受信された電子メールがマルチパート構造か否か判定する第1判定手段、前記第1判定手段により前記受信された電子メールがマルチパート構造と判定された場合に、前記受信された電子メールに文字列"message/delivery-status"が含まれているか否かを判定する第2判定手段、前記第2判定手段により前記受信された電子メールに文字列"message/delivery-status"が含まれていないと判定された場合に、前記受信された電子メールの情報に含まれる本文がテキスト形式から変更されていないか否かを判定する第3判定手段、前記第3判定手段により前記本文がテキスト形式から変更されていないと判定された場合に、前記受信された電子メールの情報のうち元の電子メールの情報が設定されている部分に、前記記憶手段に記憶されている前記所定の識別情報、送信日時及び送信先の電子メールアドレスが全て含まれているか否かを判定することで、前記受信された電子メールに対応する前記所定の電子メールの情報が含まれているか否かを判定する第4判定手段、及び、前記第1判定手段により、前記受信された電子メールがマルチパート構造と判定され、かつ前記第2判定手段により、前記受信された電子メールに文字列"message/delivery-status"が含まれていないと判定され、かつ前記第3判定手段により、前記本文がテキスト形式から変更されていないと判定され、かつ前記第4判定手段により、前記受信された電子メールの情報に、前記受信された電子メールに対応する前記所定の電子メールの情報が含まれていると判定された場合に、前記受信された電子メールに対応する所定の電子メールが送信先に届かなかったとの判定結果を出力する出力手段として機能させる。
請求項6記載の発明に係るメール不達判定プログラムは、コンピュータを、上記のメール送信手段、第1判定手段、第2判定手段、第3判定手段、第4判定手段及び出力手段として機能させるためのプログラムであるので、コンピュータが請求項6記載の発明に係るメール不達判定プログラムを実行することで、コンピュータが請求項1に記載のメール不達判定装置として機能することになり、請求項1記載の発明と同様に、送信した電子メールの不達を簡単かつ高精度に判定することができる。
以上説明したように本発明は、シングルパート構造で本文がテキスト形式で記述された所定の電子メールを、本文に所定の識別情報を付加し、任意の電子メールアドレスを送信先として送信すると共に、所定の電子メールの情報の一部として、所定の識別情報、送信日時及び送信先の電子メールアドレスを記憶手段に各々記憶させ、所定の電子メールに設定された送信元電子メールアドレスを送信先とする電子メールが受信された場合に、受信電子メールがマルチパート構造か否か判定し、受信電子メールがマルチパート構造の場合に、受信電子メールに文字列"message/delivery-status"が含まれているか否かを判定し、受信電子メールに文字列"message/delivery-status"が含まれていない場合に、受信電子メールの情報に含まれる本文がテキスト形式から変更されていないか否かを判定し、本文がテキスト形式から変更されていない場合に、受信された電子メールの情報のうち元の電子メールの情報が設定されている部分に、記憶手段に記憶されている所定の識別情報、送信日時及び送信先の電子メールアドレスが全て含まれているか否かを判定することで、受信電子メールの情報に対応する所定の電子メールの情報が含まれているか否かを判定し、受信電子メールの情報に対応する所定の電子メールの情報が含まれている場合に、受信電子メールに対応する所定の電子メールが送信先に届かなかったとの判定結果を出力するようにしたので、送信した電子メールの不達を簡単かつ高精度に判定することができる、という優れた効果を有する。
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図1には本実施形態に係るコンピュータ・システム10が示されている。コンピュータ・システム10はウェブサイト運営システム12を備えている。ウェブサイト運営システム12は特定ウェブサイトを運営するシステムであり、ウェブ・サーバ14、アプリケーション・サーバ16、メール送受信サーバ18及びメールサーバ20がイントラネット(図示省略)を介して互いに接続されて構成されている。
ウェブサイト運営システム12の各サーバのうち、ウェブ・サーバ14及びメールサーバ20はインターネット22に接続されている。なお図1では、インターネット22に接続された多数台のサーバのうちメールサーバ24のみ示している。メールサーバ24は自ドメインのメールボックスを管理し、インターネット22上の電子メールを配送したり、自ドメイン宛に届いた電子メールを対応するメールボックスに格納する等の処理を行う。またインターネット22には、各々パーソナル・コンピュータ(PC)や、インターネット22にアクセスする機能を備えたPDA(Personal Digital Assistance)、携帯電話機等の携帯端末から成る多数台のクライアント端末26が接続されている。
ウェブ・サーバ14、アプリケーション・サーバ16、メール送受信サーバ18及びメールサーバ20は同様の構成であり、メール送受信サーバ18を例にその構成を説明すると、メール送受信サーバ18は、CPU18A、RAM等から成るメモリ18B、HDD(Hard Disk Drive)18C、ネットワークインタフェース(I/F)部18Dを備え、ディスプレイ30、キーボード32及びマウス34が各々接続されている。また、メール送受信サーバ18のHDD18Cには、受信フォルダとして用いられる記憶領域が設けられ、送信メール情報DB(データベース)が記憶されていると共に、CPU18Aが後述するテストメール送信処理を行うためのテストメール送信プログラム、メール不達判定を行うためのメール不達判定プログラムが各々インストールされている。なお、メール不達判定プログラムは本発明に係るメール不達判定プログラムに対応しており、CPU18Aがこのプログラムを実行することで、メール送受信サーバ18は本発明に係るメール不達判定装置として機能する。またメール送受信サーバ18は、CPU18Aがテストメール送信プログラムを実行することで、請求項1等に記載のメール送信手段としても機能する。
次に本実施形態の作用を説明する。ウェブ・サーバ14は、インターネット22経由で任意のクライアント端末26から特定ウェブサイトがアクセスされる毎に、特定ウェブサイト内のウェブページの情報をインターネット22経由でアクセス元のクライアント端末26へ配信する処理を行う。また、本実施形態に係るウェブサイト運営システム12によって運営される特定ウェブサイトは、事前に利用者情報を登録した正規の利用者に対して所定のサービスを提供するウェブサイトであり、ウェブ・サーバ14は、任意のクライアント端末26から特定ウェブサイトがアクセスされると、まず、クライアント端末26を操作している利用者に対してログイン操作又は利用者情報入力操作を要求する内容のウェブページの情報をアクセス元のクライアント端末26へ配信する。
アプリケーション・サーバ16のHDDには、個々の正規の利用者についてユーザIDやパスワード等の認証情報や氏名、住所、電子メールアドレスを含む利用者情報が各々登録された利用者情報DBが記憶されており、ユーザIDやパスワード等の認証情報を入力するログイン操作が利用者によって行われ、利用者によって入力された認証情報をクライアント端末26から受信した場合、ウェブ・サーバ14は受信した認証情報をアプリケーション・サーバ16へ転送する。これにより、アプリケーション・サーバ16では転送された認証情報が利用者情報DBに登録されているか否かを確認することで、ログイン操作を行った利用者が正規の利用者か否かを判定する利用者認証処理を行い、その結果をウェブ・サーバ14へ通知する。ログイン操作を行った利用者が利用者認証処理によって正規の利用者であると判定されると、当該正規の利用者が操作するクライアント端末26からの要求に応じて、ウェブ・サーバ14は、特定のウェブサイト内の任意のウェブページの情報を前記クライアント端末26へ配信する処理を行い、アプリケーション・サーバ16は所定のサービスを提供する処理(例えば特定ウェブサイトが、所定の金融取引の実行をオンラインで指示可能とするサービスを提供するウェブサイトであれば、クライアント端末26を介して正規の利用者より要求された所定の金融取引を実行する処理)を行う。
一方、クライアント端末26を操作している利用者によって利用者情報登録操作が行われる場合、ウェブ・サーバ14は、氏名や住所、パスワード、電子メールアドレス等の利用者情報を入力するためのウェブページを前記クライアント端末26へ配信する。そして、前記ウェブページを介して氏名や住所、パスワード、電子メールアドレス等の利用者情報を入力する利用者情報入力操作が利用者によって行われ、利用者によって入力された利用者情報をクライアント端末26から受信すると、ウェブ・サーバ14は受信した利用者情報をアプリケーション・サーバ16へ転送し、アプリケーション・サーバ16はウェブ・サーバ14から転送された利用者情報を利用者情報DBに登録する。
ところで、上記の利用者情報のうちの電子メールアドレスは、ウェブサイト運営システム12が特定の利用者へ何らかの通知を行う必要が生じた場合に用いられる。すなわち、特定の利用者へ何らかの通知を行う必要が生じた場合、特定の利用者への通知内容及び特定の利用者の電子メールアドレスがアプリケーション・サーバ16からメール送受信サーバ18へ転送され、メール送受信サーバ18は転送された通知内容を記載した電子メールを作成し、作成した電子メールの送信先としてアプリケーション・サーバ16から転送された電子メールアドレスを設定した後に、当該電子メールをメールサーバ20を介して送信する。これにより、上記の電子メールは、メールサーバ20からインターネット22に接続された複数台のメールサーバ24を経由して送信先として設定された電子メールアドレスに明示されているドメイン(電子メールアドレスのうち"@"の右側の文字列が表すドメイン)のメールサーバ24に届き、特定の利用者のメールボックス内に格納される。そして、特定の利用者がクライアント端末26を介して自身宛に届いた電子メールを受信する操作を行うことで、特定の利用者のメールボックスからクライアント端末26へ電子メールが転送され、特定の利用者によって電子メールが受信されることで特定の利用者への通知が為される。
しかし、先に説明した利用者情報の登録時に利用者によって入力された電子メールアドレスに誤りがあった等の場合、上記のような電子メールの送信を行っても送信した電子メールが利用者に届かないので、利用者への通知を行うことができないという不都合が生ずる。このため、アプリケーション・サーバ16は、利用者情報の登録時にウェブ・サーバ14から利用者情報が転送されると、転送された利用者情報に含まれる電子メールアドレスが電子メールの届かない不適正なアドレスでないかを判定するために、上記電子メールアドレスをメール送受信サーバ18に転送し、メール送受信サーバ18に対してテストメール(電子メールアドレスが不適正なアドレスでないかを判定するための電子メール)の送信を指示する。アプリケーション・サーバ16から電子メールアドレスが転送されてテストメールの送信が指示されると、メール送受信サーバ18は、CPU18Aがテストメール送信プログラムを実行することで、図2に示すテストメール送信処理を行う。
このテストメール送信処理では、まずステップ50において、シングルパート構造で、所定の内容の本文をテキスト形式で記述し、添付ファイルの無いテストメールを作成する。またステップ52では、ステップ50で作成したテストメールに対し、アプリケーション・サーバ16から通知された電子メールアドレスを送信先として設定する。なお、テストメールの送信元電子メールアドレスとしては、メールサーバ20に設けられた特定のメールボックスに対応する電子メールアドレスが設定される。
またメール送受信サーバ18は、テストメール送信処理によって送信する個々のテストメールに対し、テストメールの送信順に通番を付与しており、次のステップ54では、ステップ50で作成したテストメールについてアプリケーション・サーバ16から送信が指示された日時と、ステップ50で作成したテストメールに付与した通番から成る情報をハッシュ関数に入力してハッシュ値を演算し、演算したハッシュ値を10進数に数値化した値をテストメールの本文の末尾にメール特定ハッシュとして付加する。なお、メール特定ハッシュの生成に用いる情報としては上記の日時及び通番に限られるものではなく、本実施形態では、メール特定ハッシュを個々のテストメールを識別するための識別情報として用いているので、個々のテストメール毎に相違する情報であれば、当該情報を用いて生成されるメール特定ハッシュも個々のテストメール毎に相違するので、メール特定ハッシュの生成に利用可能である。
そしてステップ56では、メールサーバ20に対したテストメールの送信を指示する。これにより、シングルパート構造で、本文がテキスト形式で記述され、メール特定ハッシュが付加されたテストメールが、メールサーバ20により、アプリケーション・サーバ16から通知された電子メールアドレスを送信先としてインターネット22経由で送信される。またステップ58では、送信されたテストメールの情報からメール特定ハッシュ、送信日時及び送信先メールアドレスを抽出し、これらを対応付けて送信メール情報DBに登録し、テストメール送信処理を終了する。
上記のテストメール送信処理によって送信されたテストメールは、メールサーバ20からインターネット22に接続された複数台のメールサーバ24を経由し、通常は、送信先として設定された電子メールアドレスに明示されているドメインのメールサーバ24に届き、利用者情報を入力した利用者のメールボックス(電子メールアドレスのうち"@"の左側の文字列に対応するメールボックス)内に格納される。そして、利用者が電子メールを受信する操作を行うことで、利用者のメールボックスからクライアント端末26へテストメールが転送され、利用者によってテストメールが受信される。本実施形態では、利用者情報入力操作を行いウェブサイト運営システム12からテストメールを受信した利用者が、受信したテストメールに対して返信操作を行う必要は無く、テストメールの本文にも返信操作が不要である旨が明示されているので、テストメールに返信する電子メールは利用者からは通常送信されない。
一方、利用者情報の登録時に利用者によって入力された電子メールアドレスに誤りがあった場合(例えば電子メールアドレスのうち"@"の左側の文字列に対応するメールボックスが存在しない等の場合)は、テストメールを受け取ったメールサーバ24(テストメールに送信先として設定された電子メールアドレスに対応するメールサーバ24)が、受け取ったテストメールを電子メールアドレスによって指定されたメールボックス内に格納できない(テストメールが不達となる)ことで、上記メールサーバ24により、テストメールに設定されている送信元アドレスを送信先として設定した所定の書式のエラーメールが作成され、作成されたエラーメールが送信される。また、テストメールに送信先として設定された電子メールアドレスに対応するメールサーバ24が一時的に不調となっていた等の場合は、当該メールサーバ24へテストメールを転送しようとした別のメールサーバ24がテストメールを転送できない(テストメールが不達となる)ことで、上記別のメールサーバ24によって同様のエラーメールが作成・送信される。そして、送信されたエラーメールは複数台のメールサーバ24を経由してウェブサイト運営システム12のメールサーバ20に届き、メールサーバ20に設けられた特定のメールボックスに格納される。
但し、メールサーバ20に届いて特定のメールボックスに格納されるエラーメールは不特定のメールサーバ24によって送信されるエラーメールであるので、その内容や書式は多種多様であり、RFCの規約に準拠しないエラーメールも多数混在している。また、前述のようにテストメールに対する返信操作は不要であるにも拘わらず、テストメールを受信した利用者によっては、受信したテストメールに返信する電子メールを作成・送信する返信操作が誤って行われる可能性があり、特定のメールボックスには、利用者が返信操作を行うことで送信された電子メールも格納される可能性がある。更に、特定のメールボックスの電子メールアドレスは公開しているので、特定のメールボックス宛に無関係な電子メール(所謂スパムメール等)が送信される可能性もある。
このため、メール送受信サーバ18では、CPU18Aによってメール不達判定プログラムを一定周期で繰り返し実行させることで、以下で説明するメール不達判定処理を一定周期で繰り返し行っている。このメール不達判定処理では、まずステップ60において、メールサーバ20の特定のメールボックスにアクセスし、特定のメールボックスに新たに格納された電子メール(新着メール)の取得(受信フォルダへのダウンロード)を試行する。次のステップ62では、ステップ60で特定のメールボックスから新着メールを取得できたか否か判定する。判定が否定された場合はメール不達判定処理を一旦終了する。
一方、特定のメールボックスから新着メールを取得できた場合は、ステップ62の判定が肯定されてステップ64へ移行し、取得した新着メールの中から単一の新着メールを判定対象の電子メールとして取り出す。次のステップ66では判定対象の電子メールがマルチパート構造か否か判定する。例として図4に示すように、マルチパート構造の電子メール中には文字列"Content-Type:multipart/*"(但し"*"は任意の文字列)が存在しているので、上記の判定は、判定対象の電子メールに対して上記文字列を検索し、検索の結果上記文字列が抽出されたか否かを判定することで行うことができる。このマルチパート構造はRFCの規約に準拠したエラーメールの特徴の1つであるが、エラーメールは、RFCの規約に準拠しないエラーメールであっても、少なくとも「マルチパート構造」という条件は満たしていることが本願発明者等によって確認されている。このため、ステップ66の判定が否定された場合(判定対象の電子メールがシングルパート構造の場合)は、判定対象の電子メールはエラーメールでないと判断できるので、ステップ62へ戻り、別の新着メールが無ければ処理を終了し、別の新着メールがあればこれを判定対象の電子メールとして取り出す。
メール送受信サーバ18によって作成・送信されるテストメールはシングルパート構造であり、シングルパート構造の電子メールに対して利用者が返信操作を行うことでクライアント端末26から送信される電子メールは、通常、シングルパート構造のまま維持されるので、ステップ66の判定により、受信したテストメールに対して利用者が返信操作を行うことで送信された電子メールを判定対象から除外することができる。なお、ステップ66は本発明に係る第1判定手段に対応している。
一方、ステップ66の判定が肯定された場合(判定対象の電子メールがマルチパート構造の場合)はステップ68へ移行し、判定対象の電子メールに対して第1文字列"message/delivery-status"の検索を行い、次のステップ70において、ステップ68の検索によって第1文字列が抽出されたか否か判定する。なお、ステップ68,70は本発明に係る第2判定手段に対応している。判定対象の電子メールがRFCの規約に準拠したエラーメールである場合は、例として図4にも示すように、判定対象の電子メールの中に上記の第1文字列が存在しているので、ステップ70の判定が肯定された場合、判定対象の電子メールはテストメールが不達となったことでメールサーバ24から送信されたエラーメールであると判断できる。
このため、ステップ70の判定が肯定された場合はステップ72へ移行し、判定対象の電子メールに対応するテストメールに送信先として設定した電子メールアドレスを認識する。この電子メールアドレスの認識は、まず判定対象の電子メールの中に存在しているメール特定ハッシュを探索し、この探索によって発見されたメール特定ハッシュを判定対象の電子メールから抽出し、抽出したメール特定ハッシュをキーにして送信メール情報DBを検索し、当該検索によって抽出されたメール特定ハッシュと対応付けて送信メール情報DBに登録されている送信先メールアドレスを送信メール情報DBから抽出することで行うことができる。ステップ72の処理を行うとステップ102へ移行し、アプリケーション・サーバ16に対し、ステップ72で認識した電子メールアドレスを、送信した電子メールが不達となる無効な電子メールアドレスとして通知し、ステップ62へ戻る。なお、ステップ102は本発明に係る出力手段に対応している。
これにより、アプリケーション・サーバ16は、利用者情報の登録時に利用者によって入力された電子メールアドレスが不適であることを認識することができ、利用者に対し、入力された電子メールアドレスの再確認を要請し、必要に応じて電子メールアドレスを修正させる処理を行うことができる。なお、この電子メールアドレスの再確認を要請する等の処理を行う時期はエラーメールを受信したタイミングに依存し、テストメール送信後、対応するエラーメールを直ちに受信した場合は、利用者情報を入力した直後の利用者に対して上記処理を行うことができるが、テストメールを送信してから対応するエラーメールを受信するまでに数時間〜1日程度の時間差が生じた場合は、利用者が次に特定ウェブサイトにアクセスした際に上記処理を行われる。
ところで、先のステップ70の判定が否定された場合、RFCの規約上でのエラーメールの条件には該当しないものの、本願発明者等により、第1文字列"message/delivery-status"を含まないエラーメールを送信するメールサーバも存在していることが確認されているので、上記の場合にも判定対象の電子メールがエラーメールである可能性はある。このため、本実施形態に係るメール不達判定処理では、ステップ70の判定が否定された場合に、判定対象の電子メールに対して更に以下の処理を行う。
すなわち、ステップ70の判定が否定された場合は、まずステップ74において、判定対象の電子メールに対して第2文字列"text/html"を検索し、次のステップ76では、ステップ74の検索によって判定対象の電子メールから第2文字列が抽出されたか否か判定する。この第2文字列は、電子メールの本文がHTML形式で記述されている場合に電子メールに付加される文字列であり、ステップ76の判定が肯定された場合、判定対象の電子メールは本文がHTML形式で記述されている。前述のように、メール送受信サーバ18から送信されるテストメールはテキスト形式で本文が記述されており、また本願発明者等は、テキスト形式で本文が記述された電子メールが不達となった場合、メールサーバから送信されるエラーメールの本文はテキスト形式から変更されないという特徴があることを確認している。従って、ステップ76の判定が肯定された場合、判定対象の電子メールはエラーメールではなく、例えば利用者が作成して送信した電子メール、或るはスパムメール等の無関係な電子メールであると判断できる。このため、ステップ76の判定が肯定された場合はステップ62へ戻り、別の新着メールが無ければ処理を終了し、別の新着メールがあればこれを判定対象の電子メールとして取り出す。
また、ステップ76の判定が否定された場合はステップ78へ移行し、判定対象の電子メールにファイルが添付されているか否か判定する。前述のように、メール送受信サーバ18から送信されるテストメールには添付ファイルが無く、また本願発明者等は、メールサーバから送信されるエラーメールにファイルが追加添付されることはまず無いという特徴があることを確認している。従って、ステップ78の判定が肯定された場合、判定対象の電子メールはエラーメールではなく、例えば利用者が作成して送信した電子メール、或るはスパムメール等の無関係な電子メールであると判断できる。このため、ステップ78の判定が肯定された場合もステップ62へ戻り、別の新着メールが無ければ処理を終了し、別の新着メールがあればこれを判定対象の電子メールとして取り出す。なお、上述したステップ74〜ステップ78は本発明に係る第3判定手段に対応しており、特にステップ74,76は請求項3に記載の第3判定手段、ステップ78は請求項4に記載の第3判定手段に対応している。
また、ステップ78の判定が否定された場合はステップ80へ移行し、判定対象の電子メールの中にメール特定ハッシュが存在しているか否かを探索し、次のステップ82では、ステップ80の探索によって判定対象の電子メールの中にメール特定ハッシュが存在していたか否か判定する。ステップ82の判定が肯定された場合はステップ84へ移行し、ステップ80の探索によって発見したメール特定ハッシュを判定対象の電子メールから抽出した後に、抽出したメール特定ハッシュをキーにして送信メール情報DBを検索する。次のステップ86では、ステップ84の検索によって送信メール情報DBからメール特定ハッシュが抽出されたか(判定対象の電子メールから抽出したメール特定ハッシュが送信メール情報DBに登録されていたか)否か判定する。
ステップ86の判定も肯定された場合はステップ88へ移行し、判定対象の電子メールに対し、元のテストメールの送信日時に相当すると推定される情報(例えば判定対象の電子メールの情報のうち元のテストメールに相当すると推定される部分に存在している文字列"Date:"に続く文字列)を探索し、次のステップ90では、ステップ88の探索によって発見した元のテストメールの送信日時に相当すると推定される情報を判定対象の電子メールから抽出した後に、抽出した情報をキーにして送信メール情報DBを検索する。ステップ92では、ステップ90で検索した情報が送信メール情報DBに送信日時として登録されていたか否か判定する。なお、この判定が肯定された場合に、ステップ90の検索で送信メール情報DBから抽出された情報(送信日時)が、先のステップ84の検索でキーとして用いたメール特定ハッシュと対応付けて送信メール情報DBに登録されているか否かを更に判定するようにしてもよい。
ステップ92の判定も肯定された場合はステップ94へ移行し、判定対象の電子メールに対し、元のテストメールの送信先メールアドレスに相当すると推定される情報(例えば判定対象の電子メールの情報のうち元のテストメールに相当すると推定される部分に存在している文字列"To:"に続く文字列)を探索し、次のステップ96では、ステップ94の探索によって発見した元のテストメールの送信先メールアドレスに相当すると推定される情報を判定対象の電子メールから抽出した後に、抽出した情報をキーにして送信メール情報DBを検索する。ステップ98では、ステップ96で検索した情報が送信メール情報DBに送信先メールアドレスとして登録されていたか否か判定する。なお、この判定が肯定された場合に、ステップ94の検索で送信メール情報DBから抽出された情報(送信先メールアドレス)が、先のステップ84の検索でキーとして用いたメール特定ハッシュ及び先のステップ90の検索でキーとして用いた送信日時と対応付けて送信メール情報DBに登録されているか否かを更に判定するようにしてもよい。
ステップ98の判定も肯定された場合は、送信メール情報DBに登録されているメール特定ハッシュ、送信日時及び送信先メールアドレスが判定対象の電子メールの中に各々存在しているので(図4も参照)、判定対象の電子メールには対応するテストメールの情報が含まれていると判断できる。また本願発明者等は、或る電子メールが不達となった場合にメールサーバから送信されるエラーメールには、元の電子メールの情報が含まれているという特徴があることを確認している。従って、ステップ92の判定も肯定された場合、判定対象の電子メールはエラーメールであると判断できるので、ステップ102へ移行し、アプリケーション・サーバ16に対し、先のステップ88で抽出した電子メールアドレスを、送信した電子メールが不達となる無効な電子メールアドレスとして通知し、ステップ62へ戻る。この場合も、アプリケーション・サーバ16は、利用者に対して入力された電子メールアドレスの再確認を要請する等の処理を行うことができる。
以上の処理を行うことで、受信した電子メールがエラーメールか否か、すなわち対応するテストメールが送信先に届かなかったかを高精度に判定することができ、利用者によって入力された電子メールアドレスが、送信した電子メールが不達となる無効な電子メールアドレスか否かを高精度に判定することができる。また、上記の処理における各判定は、テーブルに登録するための文字列を収集したり、テーブルに登録した文字列を定期的に更新する等の煩雑な作業又は処理も不要であるので、受信した電子メールがエラーメールか否か、すなわち対応するテストメールが送信先に届かなかったかの判定を容易に行うことができる。
なお、上記のメール到達判定処理において、ステップ82,86,92,98の何れかの判定が否定された場合、判定対象の電子メールには送信した何れのテストメールの情報も含まれていないと判断できるので、判定対象の電子メールがエラーメールである可能性は極めて低いものの、この場合、判定対象の電子メールは、マルチパート構造であり、本文がテキスト形式で記述されており、添付ファイルも無いという特徴を備えているので、判定対象の電子メールをエラーメールでないと断定すると判定に漏れが生ずる可能性がある。このため、本実施形態に係るメール不達判定処理では、判定の漏れを無くすことを優先し、ステップ82,86,92,98の何れかの判定が否定された場合はステップ100へ移行し、判定対象の電子メールを解析不能と判定して所定のフォルダに格納した後にステップ62に戻る。この場合、所定のフォルダに格納された電子メールに対する解析(エラーメールか否かの判定)は、オペレータに委ねられることになるが、ステップ100で所定のフォルダに格納される電子メールの割合は極めて低く、所定のフォルダに格納された電子メールに対する解析がオペレータの負担となることはない。
なお、上記では利用者情報の登録時に、利用者によって入力された電子メールアドレスに誤り等が無いかを確認するために、テストメールを送信してメール不達判定処理を行う態様を説明したが、本発明はこれに限定されるものではなく、送信した電子メールがメールサーバの一時的な不調等によっても不達となる可能性があることを考慮し、例えば重要な内容の電子メールを送信した後に上記のメール不達判定処理を行い、送信した電子メールの不達(エラーメールとして戻ってきていないか)を監視する、等の態様に適用することも可能である。
また、上記ではウェブサイト運営システム12のメール送受信サーバ18を本発明に係るメール不達判定装置として機能させる態様を説明したが、メール不達判定装置として機能させるコンピュータ(請求項6に記載のコンピュータ)は上記に限られるものではなく、例えばPC等の他のコンピュータをメール不達判定装置として機能させることも可能である。
また、上記では本発明に係るメール不達判定プログラムがメール送受信サーバ18に予め記憶(インストール)されている態様を説明したが、本発明に係るメール不達判定プログラムは、CD−ROMやDVD−ROM等の記録媒体に記録されている形態で提供することも可能である。