(57)【要約】      （修正有）【課題】大量にメールを送信する場合に、インターネットサービスプロバイダーによる受信ブロックを回避しつつ、かつ実効性のあるリストクリーニングを行なう。【解決手段】インターネットメールに用いられる電子メールアドレスのリストをクリーニングに関し、電子メールアドレスリストを読み込み、読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行ない、上記の電子メール送出に対するバウンスメールを解析し、前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除することを特徴とするリストクリーニング方法、並びにこれを実現するためのプログラム及び装置。【選択図】図３
2006318070.tif 000002
【特許請求の範囲】
【請求項１】
電子メールアドレスのリストをクリーニングする方法であって、
電子メールアドレスリストを読み込む手順、
読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう手順、
上記の電子メール送出に対するバウンスメールを解析する手順、
前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する手順、
を有することを特徴とする、リストクリーニング方法。
【請求項２】
前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項１に記載のリストクリーニング方法。
【請求項３】
前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項１又は請求項２に記載のリストクリーニング方法。
【請求項４】
電子メールアドレスのリストをクリーニングするためのプログラムであって、
電子メールアドレスリストを読み込む処理、
読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう処理、
上記の電子メール送出に対するバウンスメールを解析する処理、
前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する処理、
をコンピュータに実行させるためのプログラム。
【請求項５】
前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項４に記載のプログラム。
【請求項６】
前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項４又は請求項５に記載のプログラム。
【請求項７】
電子メールアドレスのリストをクリーニングする装置であって、
電子メールアドレスリストを読み込む手段、
読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう手段、
上記の電子メール送出に対するバウンスメールを解析する手段、
前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する手段、
を有することを特徴とする、リストクリーニング装置。
【請求項８】
前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項７に記載のリストクリーニング装置。
【請求項９】
前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項７又は請求項８に記載のリストクリーニング装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールアドレスのリストから、無効ないし使用されていない電子メールアドレスを取り除くための方法、並びにこれを実現するためのソフトウェア及び装置に関する。
【背景技術】
【０００２】
［クリーニングの必要性］
電子メールの普及により、電子メールによる広告・宣伝等が多用されるようになった。すなわち、様々な方法により多数の電子メールアドレスを収集して作成されたリスト（データベース）に基づき、電子メールにより送信される広告、宣伝等が頻繁に行なわれるようになった。
このように、多数の宛先に同一の内容の情報を送付する場合、電子メールを用いれば、従来の紙ベースによる郵便を使用した場合と比べて、圧倒的に容易かつ安価にこれを実現することができる。
【０００３】
一方，本人の希望しないメールが送りつけられる迷惑メールが社会問題化しており，これを避けるために頻繁にメールアドレスが変更されるといった現象が特に携帯電話では顕著になってきている。また，携帯キャリアやインターネットプロバイダを変更した時，あるいは職場や部署の変更などのタイミングでアドレスが変更されることも多い。
このように、電子メールアドレスは頻繁に変更されるものであるため、電子メールアドレスリストを作成しても、これを一定期間使用し続けると、その内容のかなりの部分が無効なアドレスであることになり、内容が陳腐化してしまう。
それ以外にも、近年迷惑メール対策として長いアドレス名を使用する利用者が増えたため、利用者から電子メールアドレスを収集する過程において、誤った電子メールアドレスが記載されてしまう可能性も高くなっている。
【０００４】
以上のような状況のため、電子メールアドレスリストを使用する場合には、一定期間ごとに電子メールアドレスリストの内容を確認し、無効なアドレスを削除するなどの更新（クリーニング）が必要となる。
これは、無駄な送信を避けて効率化するという意味において必要なことはもちろんである。さらに、近年の事情として、無効なメールアドレスを多く含むリストに基づいて多量の電子メールを送信すると、これがプロバイダーによりスパムメールと判断され、その発信元からのメール受信がブロックされる（受信ブロック）という状況がある。すなわち、近年、いわゆる迷惑メール、スパムメールが増加したため、携帯電話のキャリアを始め、多くのインターネットサービスプロバイダ（ＩＳＰ）において、大量なメール送信がなされる場合には、一定以上の無効な電子メールアドレスを含む送信を行なった送信元に対し、受信ブロックが行なわれるようになっているのである。したがって、これに対応するという意味においても電子メールアドレスリストのクリーニングが必要とされる。
【０００５】
［配信方法の問題点］
電子メールアドレスリストをクリーニングする方法として最もシンプルなものは、現実に送信した後、送信不能として戻ってきたメールアドレスを、リストから取り除くという方法である。しかしながら、この方法を用いるためには、現実に一度送付を行なわなければならないため、頻繁にクリーニングが行なわれていない電子メールアドレスリストに基づいてこれを行なおうとしても、その時点でＩＳＰにより受信ブロックが行なわれてしまうことになる。
【０００６】
これとは別の従来の方法としては、特許第３３１５３６９号に記載されている方法がある。これは、電子メールを送信せずに送信先サーバに対してＳＭＴＰで接続し、差出人と宛先の情報（エンベロープヘッダ）だけを送ったときに先方から返されるリターンコードで判定するという手法である。
しかし、この方法には、配信側が接続したサーバが全てのメールを一旦受け取ってから内部へ転送する、いわゆるゲートウェイ方式を採用している場合には、存在しない宛先でも一度は受け取ってしまうため、有効に機能しないという問題があった。
実際にこのようなゲートウェイ方式を採用する構成は一般的になっており携帯キャリアの一部も同様の構成をとっている。
【０００７】
［解析方法の問題点］
また、配信システムが持つアドレスリストをエラーの少ない健全な状態に維持するためには、リターンコードを正確に解析し，アドレスのメンテナンスへフィードバックする必要がある。
従来の手法は ＲＦＣ に準拠したバウンスメールが戻ってくることを期待したものであるが、昨今のメールの爆発的な普及に伴い、多くのメールシステムにおいては、専門家でなくてもどんなエラーが起こったのかが分かりやすいようにという「配慮」から、日本語によるエラーメッセージを初め様々なメッセージのリターンコードが返ってくるようになってきており、ＲＦＣ準拠のメッセージで判定可能な例の方が少ないのが現状である。
【特許文献１】特許第３３１５３６９号
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記のように、通常の方法でメールを送信してしまうと受信ブロックが発生する可能性が生じるが、しかしこれを避けるためにエンベロープヘッダのみを送ってリターンコードにより判定するという手法を採用しても、十分に機能しない。
また、ＲＦＣ準拠のメッセージが返ってくることを前提とした従来の解析方法も、現在では十分に機能するものではない。
本発明はこれら問題点に鑑みてなされたものであり、ＩＳＰによる受信ブロックを回避しつつ、かつ実効性のあるリストクリーニングを行なう方法、並びにこれを実現するソフトウェア及び装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために本発明の請求項１記載のリストクリーニング方法は、電子メールアドレスのリストをクリーニングする方法であって、電子メールアドレスリストを読み込む手順、読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう手順、上記の電子メール送出に対するバウンスメールを解析する手順、前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する手順、を有することを特徴とする。
【００１０】
また、請求項２記載の方法は、前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項１記載のリストクリーニング方法である。
【００１１】
さらに、請求項３記載の方法は、前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項１又は請求項２に記載のリストクリーニング方法である。
【００１２】
次に、請求項４記載のプログラムは、電子メールアドレスのリストをクリーニングするためのプログラムであって、電子メールアドレスリストを読み込む処理、読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう処理、上記の電子メール送出に対するバウンスメールを解析する処理、前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する処理、をコンピュータに実行させるためのプログラムである。
【００１３】
請求項５記載のプログラムは、前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項４に記載のプログラムである。
【００１４】
請求項６記載のプログラムは、前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項４又は請求項５に記載のプログラムである。
【００１５】
請求項７記載の装置は、電子メールアドレスのリストをクリーニングする装置であって、電子メールアドレスリストを読み込む手段、読み込まれた電子メールアドレスリストから取得された電子メールアドレスにつき、その一部のみの送出と、一定時間の送出休止を繰り返すことにより電子メールの送出を行なう手段、上記の電子メール送出に対するバウンスメールを解析する手段、前記解析により無効なアドレスであると判断される電子メールアドレスにつき、これを前記電子メールアドレスリストから削除する手段、を有することを特徴とする、リストクリーニング装置である。
【００１６】
そして、請求項８記載の装置は、前記バウンスメールの解析は、前記バウンスメールが所定のエラーメッセージを含むか否かの判断を含むことを特徴とする請求項７に記載のリストクリーニング装置である。
【００１７】
最後に、請求項９記載の装置は、前記バウンスメールの解析は、エラーメッセージの特徴となるキーワードをパターン化したファイルと対比することを特徴とする請求項７又は請求項８に記載のリストクリーニング装置である。
【００１８】
［配信方法］
通常のメール配信システムでは「如何に高速に配信するか」が課題となっていた。ところが、前述のように、多くの無効電子メールアドレスを含むリストを高速に配信してしまうと、ＩＳＰの受信ブロックを受けることになる。そこで、配信速度につき、本件発明においては、受信ブロックを回避するために意図的にペースを遅くして配信することとしている。
【００１９】
配信しようとするリストにどの程度の割合で無効なアドレスが含まれているかを予測することはできないため，配信リストから無作為に抽出した小規模なリストにより予備配信を行い配信成功率の予測値を得る。その値により残りのリストを配信する際のペースを調整する。
【００２０】
［解析方法］
また、リストクリーニングを適切に行なうために、バウンスメールを解析し、その結果により、無効と判断される電子メールアドレスを前記電子メールアドレスリストから削除する。
バウンスメールの内容はＲＦＣに準拠したものばかりではないため多くのサンプルデータからとりまとめたパターンファイルの内容と比較することにより判定する。
【発明の効果】
【００２１】
本発明におけるクリーニングシステムによれば、インターネットサービスプロバイダによる受信ブロックを回避しつつ、電子メールアドレスリストをより適切な状態にクリーニングすることが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明に係る電子メールアドレスリストのクリーニング方法並びにそれを実現するソフトウェア及び装置の実施例について、図面を参照しつつ説明する。
【００２３】
［インターネットメールの概要］
図１はインターネットにおける電子メールの伝搬経路の概略を模式的に示している。
メールサーバ１はインターネットＮ１に接続されており，そのメールサーバ１にはクライアント２が接続されている。インターネットＮ１には他のメールサーバ３やメールサーバ６などのサーバ／クライアントシステムが多数接続されており相互間でインターネットメールの送受信を行う。
【００２４】
メールサーバ１はＵＮＩＸ（登録商標）などのシステムで動作しているサーバシステムである。また，クライアント２は一般的にはデスクトップＯＳに分類されるＷｉｎｄｏｗｓ（登録商標）やＭａｃＯＳなどで動作するコンピュータである。
メールサーバ１とクライアント２の間は企業内システムでは主としてＬＡＮで構成され，個人がインターネットメールを利用するような場合ではインターネットプロバイダが提供するサーバへのダイヤルアップやＡＤＳＬによる接続環境などが利用される。
メールサーバ１はクライアントからの送信処理を受け付け，別のメールサーバへ転送するあるいは別のサーバから送られてきたメールを受け取るＳＭＴＰ（Simple Mail Transfer Protocol）サーバ１ｓと受信したメールを格納するメールボックス，クライアントからのメール受信要求に対して処理を行うＰＯＰあるいはＩＭＡＰサーバ１ｐから構成される。ＤＮＳサーバｄはドメインネームシステムという機能を提供しておりインターネットメールの配送処理においては送信先アドレスのドメイン部（例：foo@sample.co.jp というアドレスであれば＠以降のsample.co.jpの部分）から送信先メールサーバのＩＰアドレスを特定するために利用される。
【００２５】
ＳＭＴＰはメールの送信側と受信側との間の通信規約でありＲＦＣ２８２１（Request for Comments 2821）として規格化されている。
クライアント２からクライアント５へのメールを送信する場合，先ずクライアント２とメールサーバ１との間でＳＭＴＰによりメールが送られる。次にメールサーバ１は宛先アドレスをＤＮＳサーバ１ｄへ問い合わせメールサーバ３のＩＰアドレスを得る。次に今度はメールサーバ１が送信側，メールサーバ３が送信先となりＳＭＴＰによるメール送信が行われる。メールサーバ３は受信したメールをメールボックスへ格納する。クライアント５はＰＯＰあるいはＩＭＡＰサーバにアクセスすることによってメールボックスへ格納されたメールを受信することができる。
【００２６】
メール環境としてはクライアント５よりはクライアント９のようにメールボックスへ格納するＳＭＴＰサーバよりも外側にメールを中継するだけのメールサーバ６を配置することが多くなっている。また，携帯電話宛のメールではＳＭＴＰで受信したメールは更に携帯キャリアの通信網（非ＴＣＰ／ＩＰ）へ中継される。
【００２７】
［クリーニングシステムの構成］
図２はクリーニングサービスを行うシステムの概要を示しており，管理サーバ１１と配信サーバ１２，エラー解析サーバ１３，ＤＢサーバ１４から構成される。
管理サーバ１１は、サービス利用端末１６からクリーニング対象のアドレスリストの登録を受け付けてＤＢサーバ１４の記憶領域へ保存したり，運用者端末１７からのオペレーションを受け付ける。
サービス利用者の実際の利用時は図７に示す運用者端末の画面でクリーニング対象のリストファイルを登録する。また，運用オペレータは図８に示す画面より配信するメールの内容を登録し，実行指示を出す。
【００２８】
クリーニング処理は、ＤＢサーバ１４の記憶領域から取り出した配信リスト１５を配信サーバ１２に対して送り出す部分と、送信したメールに対するバウンスメールをエラー解析サーバ１３で受信し解析する部分に分かれている。
【００２９】
［クリーニングの全体のフロー］
クリーニング処理の方法について図３のフローチャートを参照して説明する。
まず、配信するリストを作業用メモリ領域へ読み込む（ステップ３０１）
そして、ステップ３０２から３０８の間で、配信リストからｍ通送信してｓ秒休止するという方法を採用することによりメールを配信する速度が調整される。このとき，ｍおよびｓという２つのパラメータはASPサービスの監視結果がフィードバックされることにより適宜更新される。
ステップ３０３では、配信リストから取り出したｍ個の中から１つのアドレスを取り出す。
【００３０】
次にステップ３０４でアドレス形式の検査を行う。ステップ３０４では、メールアドレスとして正しいフォーマットになっているか，使用が禁止されている文字列が含まれていないかなどの検査を行う。
アドレス形式検査で問題が無かったものは、ステップ３０５でメール送信サーバへＳＭＴＰ接続を開始する。このときＳＭＴＰ接続するメール送信サーバは図２の配信サーバ１２である。
ステップ３０６では、ＲＦＣで既定された手順に従ってメールを送信する。
ステップ３０７において、ｍ個分の処理が終了したかを判定し，未処理のアドレスがあればステップ３０３に戻り、繰り返し処理を行う。
【００３１】
ステップ３０２で取り出したｍ個分の処理が終了したら、ステップ３０８で元の配信リストについて処理が完了したかを判定し，未処理のアドレスがある場合はｓ秒待ってからステップ３０２へ戻り次のｍ個のアドレスを取り出す。
そして、ステップ３０８において、配信リストにあった全てのアドレスについて配信処理が完了したら終了となる。  
【００３２】
次に、ステップ３０６で送信サーバが受け取ったメールの送信処理について、図４のフローチャートを参照しつつ説明する。
送信するメールを受け取った配信サーバ１２は図４のフローによりメールを送信する。
ステップ４０１で送信先アドレスのメールサーバについてＤＮＳに問い合わせ、ステップ４０２の判断において正常な結果が得られない場合は、ステップ４０６によりバウンスメールを送信する。
送信先サーバのＩＰアドレスが取得できた場合はステップ４０３にて相手メールサーバへＳＭＴＰ接続し，ステップ４０４でＲＦＣに規定された手順に従ってメールを送信する。
ステップ４０４のメール送信処理が正常に終了しなかった場合はステップ４０６によりバウンスメールを送信する。ここでバウンスメールを送信する先は図２におけるエラー解析サーバ１３である。
【００３３】
ステップ４０４におけるＲＦＣで規定されたメール送信手順について図５のフローを参照して説明する。便宜上，送信元のアドレスを userA@host.foo.jp 送信先のアドレスを
userB@mail.sample.jp として説明する。
ステップ（１）で既にＤＮＳサーバより取得したＩＰアドレスへ対してＴＣＰポート２５へ接続する。
接続が成功するとステップ（２）で相手のサーバから応答コード「220」が返される。
ステップ（３）で送信元のドメイン名を通知し，正常に受理されるとステップ（４）で応答コード「250」が返される。
【００３４】
ステップ（５）で送信者のアドレス userA@host.foo.jp を通知し，正常に受理されるとステップ（６）で応答コード「250」が返される。
続いてステップ（７）で送信先のアドレス userB@mail.sample.jp を通知し，正常に受理されるとステップ（８）で応答コード「250」が返される。
ここで相手のサーバ構成によっては存在しないアドレスを指定した場合や相手のメールアドレスのメールボックスが容量制限を超えていて受信できない場合などのエラーが返されるので，図４のステップ４０４と同様に図２のエラー解析サーバ１３へバウンスメールを送信する。
【００３５】
図２のＳＭＴＰゲートウェイ２２のような、サーバとのＳＭＴＰ処理の場合は、送信したメールを、受け取った後にＳＭＴＰサーバ２３へ転送される。したがって再度ＳＭＴＰゲートウェイ２２とＳＭＴＰサーバ２３の間でＳＭＴＰ処理が行われることになり，バウンスメールが発生した場合はＳＭＴＰサーバ２２から返される。
ステップ（８）が正常に終了した場合は、ステップ（９）でデータ送信開始の合図を通知し，受信側の準備ができたらステップ（１０）で応答コード「354」が返される。
ステップ（１１）でメールデータ（From，To，Subject，本文など）を送信し，ステップ（１２）で終了の合図を通知する。
最後に応答コード「221」が返され，送信処理は終了となる。
【００３６】
次に、バウンスメール解析の方法について説明する。
［バウンスメールの受信経路］
メールの送信処理で述べたようにバウンスメールは図２における配信サーバ１２から返される場合と相手側のゲートウェイサーバ２２から返される場合がある。
【００３７】
［バウンスメールのバリエーション］
配信サーバ１２から返されるバウンスは常に決まった構成となるが，相手側のサーバから返されるようなバウンスは、様々な種類のサーバがあるため様々な構成のバウンスとなる。大きく分類すると、配信した元のメールの内容が添付ファイル形式で返されるマルチパート形式と、バウンスメールの本文に引用されているシングルパート形式とに分かれる。
また，エラーメッセージの部分は必ずしもＲＦＣに準拠したメッセージで記載されておらず，日本語で書かれている場合や英語と併記されているもの，文字列の並び方を意識した仕様なのか，メッセージの途中で改行されているものなど様々である。
【００３８】
［パターンファイル化による管理］
このようにエラーメッセージには様々なパターンがあるため、バウンスメール解析部においては、エラーメッセージの特徴となるキーワードをパターンファイル化して記憶領域上において管理する。
実際のエラーメッセージには、キーワードの前後に関連する文字列が差し込まれている場合も多いため、単純なパターン化では管理が煩雑になってしまう。そこで、正規表現を用いたパターンファイルで管理することで少ないパターンでより多くのエラーメッセージを処理するようになっている。
【００３９】
［特殊処理モジュール］
また，いくつかの主要ベンダーのグループウェアやメールサーバから返ってくるバウンスメールや特定の携帯キャリアから返ってくるバウンスメールではパターンとの照合だけではなく特殊な処理が必要になる場合がある。具体的にはマルチパート形式で返ってくるバウンスメールでは何番目のパートで判断するか，エラーメッセージの途中で改行されてしまっている場合，２つ以上のキーワードの組み合わせで判断する必要がある場合などである。
このようなバウンスメールを解析するため、前記バウンスメール解析部においては、受信したバウンスのヘッダ部分から特殊対応が必要か否かを判定し，必要に応じて特殊処理のモジュールを呼び出す仕組みが採用されている。
また，この「特殊処理モジュール」は後から追加可能なようになっており新たな対応が必要になった場合でも柔軟に対応できる
特殊モジュールが必要かどうかは受信したバウンスメールのヘッダ部から相手のサーバタイプを特定して判定する。
【００４０】
［バウンスメール解析フロー］
図６のフローチャートを参照してバウンス解析の流れを説明する。
ステップ６０１でパターンファイルおよび各種設定ファイルを読み込む。
ステップ６０２で解析対象のバウンスメールを読み込む。
ステップ６０３でヘッダ部を読み込む。
ステップ６０４で外部からのバウンスメールかどうかを判定し，外部から返されたバウンスメール（図２における配信サーバ１２以外から返って来た場合）であった場合は、ステップ６０５で相手側サーバタイプを判定したのち、ステップ６０６で特殊処理モジュールの適用対象かどうかを判定する。
ステップ６０７ではステップ６０６の結果に対応したモジュールを呼び出し，ステップ６０８以降の処理に適用できるような変換処理を行う。
ステップ６０７での特殊モジュール適用後、もしくはステップ６０６で特殊モジュールが不要と判断されたものは、ステップ６０８でシングルパート，マルチパートに分類されステップ６０９，６１０で解析対象部分を読み込む。
ステップ６１１でパターンファイルとの照合を行う。
【００４１】
パターンファイルにはバウンスメッセージ本文と比較するキーワードが登録されており，キーワードはバウンス種別毎に分類され，固有のコードが付与されている。
バウンス種別は以下のように分類される。
・TimeOut：タイムアウト（規定時間内に送信できなかった）
・MailboxFull：相手メールボックスの容量がオーバーしている
・ServerEnv：相手メールサーバの環境に依存したエラーが発生した
・HostUnknown：送信するべきメールサーバが見つからない
・UserUnknown：宛先不明（存在しないメールアドレス）
・ReceiveReject：受信拒否
・OtherFatal：その他
パターン固有のコードは上記バウンス種別に対応したコードとメッセージの言語（英語，日本語）および連番からなり以下のようなコードとなっている。
・EN-#-00-0001
・EN-#-01-0026
【００４２】
パターンとして登録されるキーワードは正規表現を使用して登録されており，少ないパターンで似通った複数のメッセージが処理できるようになっている。たとえば、
(disk)?quota.*is
over( the limitation)?
no(
such)? (mailbox|user|recipient)
のように記載されている。
そして、ステップ６１２でパターンと一致したものは、ステップ６１３において配信リストから削除される。
これにより、リストのクリーニングなされることになる。
【００４３】
［誰宛のメールに対するエラーかの正確な把握］
なお、バウンスメールの解析においては「誰宛のメールに対するものか」を正確に把握する必要がある。しかし、受信したバウンスの差出人アドレスはバウンスメールの発信元のシステムアドレス（MAILER-DAEMON, postmasterなど）となっていることが多いため、受信したバウンスメールの内容から誰宛のメールに対するものか」を判定する必要が生じることになる。
そのためには、バウンスメールの中でエラーメッセージと共にエラーとなったメールアドレス（送信しようとしていた相手先のアドレス）が引用されているか，あるいは、元のメールの内容がヘッダ情報も含めて引用されている必要がある。ところが，受信したメールに何も情報がない場合が実際にある。また，送信したアドレスから更に別のアドレスへ転送されているような場合に転送先で発生したエラーを受信すると配信リストに存在しないアドレスがエラーになったというバウンスを受け取ることになる。
そこで、バウンスメール解析部においては、バウンスを受信するアドレスそのもので誰宛のメールだったかを把握する方法が採用されている。
【００４４】
バウンスメールは送信するメールのエンベロープヘッダ（図５のステップ（５）で通知するアドレス）にある差出人アドレスへ返るため、配信時に各メールの宛先毎に固有になるような変換を行ったアドレスを設定している。
基本的な考え方は qmail の VERPS にならっている。VERPSでは
bma-xxxxxxxxxx@<配信元ドメイン>
のような形式を持ち，先頭の bma の部分はバウンスを受信する基準となるアドレスで "-" で区切った後に宛先アドレスの "@" を "=" に置き換えた文字列をセットする。
このような命名規則のメールを全て受信するにはそれぞれに対応したメールアドレスを用意する必要があるが，基準となるアドレス "bma" が
"-" の後に続く全ての文字列をワイルドカード的に受信するような環境を用意することで解決している。
【００４５】
ところが、実際には
"=" を含むアドレスからは受信しないような設定で稼働するサーバが増えている。また、
VERPS 準拠の変換方式では最近の携帯メールアドレスのように非常に長いアドレスが宛先の場合，変換後アドレスのユーザ部が RFC で規定された最大長 64 文字を超えてしまう場合がある。
そこで、先ず
"=" を含まないように変換するために、先頭にユーザ部の長さを示す固定長フィールドを付加し，ユーザ部，ドメイン部を順に連結することとした。
たとえば、foo@sample.co.jp
宛に送信する場合のエンベロープヘッダは、VERPS による実装においては、
bma-foo=sample.co.jp@<配信元ドメイン>
となるが、本実施例のシステムにおいては、
bma-003foohogehoge.co.jp@<配信元ドメイン>
とされる。
また，本変換後のユーザ部が64バイトを超えてしまう場合には、本実施例においては、変換部分を64進数で更に可逆な変換することで短縮することとしている。
【図面の簡単な説明】
【００４６】
【図１】インターネットにおける電子メールの伝搬経路の概略を示す図である。
【図２】本発明のクリーニングサービスを行うシステムの概要を示す図である。
【図３】本発明のクリーニング処理の方法を示すフローチャートである。
【図４】送信サーバが受け取ったメールの送信処理を示すフローチャートである。
【図５】ＲＦＣで規定されたメール送信手順を示すフローである。
【図６】バウンス解析の流れを示すフローチャートである。
【図７】クリーニング対象のリストファイルを登録する画面の例を示す図である。
【図８】クリーニング対象のリストファイルを登録する画面の例を示す図である。
【符号の説明】
【００４７】
１１    管理サーバ
１２    配信サーバ
１３    エラー解析サーバ
１４    DBサーバ
１６    サービス利用者端末
１７    運用者端末
【図１】
2006318070.tif 000003
【図２】
2006318070.tif 000004
【図３】
2006318070.tif 000005
【図４】
2006318070.tif 000006
【図５】
2006318070.tif 000007
【図６】
2006318070.tif 000008
【図７】
2006318070.tif 000009
【図８】
2006318070.tif 000010