JP5427497B2 - メールゲートウェイ - Google Patents

Description

本発明は、メールゲートウェイの技術に関する。

昨今、電子メール（以下、メールと表記する）の受信者の意向を無視した、いわゆるスパムメール（スパムメールの定義は、文献により違いがあるが本稿では前述のとおり定義する）が大量に送信されており、社会問題化している。インターネットサービスプロバイダなど、メールサーバを管理する事業者（以下、通信事業者という）は、スパムメールの配信を防ぐために様々な対策を行っており、その代表的な対策にスパムメールフィルタがある。

スパムメールフィルタの例として、特許文献１の方法がある。特許文献1では、ユーザからのアラートにより特定のメールがスパムメールだと判定するステップと、それ以降に受信したメールがスパムメールまたはその変形であるか検出し、スパムメールと判定されたメールを分離することにより、スパムメールの受信または送信を防ぐ。特許文献１以外にも、スパムメールの特徴を機械学習により検出する方法や、ユーザにより検出した特徴をデータベースへ登録する方法、スパムメールとの類似性やスパムメールである確率などを計算してスパムメールを判定する方法など様々な技術が存在する。

米国特許第6732149号明細書

一方、通信事業者のメールサーバに影響を与えるメールが存在する。以下、携帯電話の通信サービスを提供している会社（携帯電話キャリアという）のメールシステムでの事例について説明する。

携帯電話キャリアは、携帯電話特有のメールサービスを提供するために、メールの文字コードや絵文字、添付されている画像などに様々な変換処理を行いながらメールを配信している。上記メールシステムの処理はメールゲートウェイというサーバで実現しているが、メールゲートウェイは想定していないメールを処理することにより、プロセスダウンなどの障害を起こす場合がある。

上記のようなメールゲートウェイは、携帯電話キャリアのネットワーク（キャリア設備網という）に、負荷分散できるように複数台設置されているが、障害を発生させるメール（以下、障害メールと定義する）が再送または大量送信された場合、他のメールゲートウェイでも次々と障害が発生し、最悪全てのメールゲートウェイが停止し、メールサービスの停止に至る可能性もある。

そこで、メールゲートウェイが障害メールを排除する方法として、特許文献１の技術を含むスパムメールメールフィルタを適用することが考えられる。しかしながら、従来のスパムメール判定方法は、スパムメールの特徴を、人または、予め与えられた情報からの機械学習で検出することを前提にしている。すなわち、従来技術では、メールゲートウェイに、メールによる障害が発生した時点から、その原因となった障害メール障害メールの特徴を把握できる時点までの間隔が長く、その間に同じ障害メールが再送または大量に送信されると、メールサービスの停止は回避できない。

また、上記の障害メールは、一般的なスパムメールと異なり、携帯電話キャリアのメールシステムとしては排除したいメールであっても、受信者は通常のメールとして受信したいメール（悪意のないメール）である場合がある。従来のスパムフィルタは受信者が受信したいメールであっても排除するため、上記問題を解決することができない。

本明細書では、上記課題を解決するために、メールゲートウェイが障害メールを受信して障害が発生したときに、速やかに原因となる障害メールを特定して、その特徴を検出することを特徴とするメールサーバの障害回避方法が開示される。さらに、メールゲートウェイが、検出した特徴を元に障害メールの分析を行い、分析の結果にもとづき、メールをなるべく排除しない処理方法を選択することを特徴とするメールサーバの障害回避方法が開示される。

開示されるメールゲートウェイは、メールを中継するメール中継プロセスとそれを監視する監視プロセスを含んで構成する。メール中継プロセスは、プロセスダウン等の障害が起こった場合に処理しているメールを特定する仕組みを持つ。

障害発生時、監視プロセスは障害の要因となったメールを特定し、そのメールの特徴を解析し取得する。また、監視プロセスは、障害が発生したプロセス、処理内容の情報を取得する。そして、監視プロセスは上記の障害で取得した情報を、障害メールの情報を記憶するテーブル（以下、障害メール情報テーブルと呼ぶ）に登録する。その後、監視プロセスはメール中継プロセスを復旧させる。また、監視プロセスは上記の障害で取得した情報はキャリア設備網内の他のメールゲートウェイに転送することも望ましい。

メール中継プロセスは、障害が発生して以降、新しい受信したメールの特徴が、障害メール情報テーブルに登録された特徴と一致した場合、そのメールを障害メールと判定する。メールゲートウェイは、障害メールとして判定したメールについて、排除するのではなく、障害が発生することが分かっている処理をスキップする処理、予想される障害の内容をユーザへ通知する処理など、複数種類からひとつ以上を状況に応じて選択する。

本発明により、メールゲートウェイにおいて特定のメール受信により障害が発生しても、再発生を防止し、メールシステムのサービス継続が可能になる。

本実施例を適用したシステムの構成を例示する図である。 本実施例を適用したメールゲートウェイ106の構成を例示する図である。 メールゲートウェイ106のプログラム構成を例示する図である。 障害メール情報テーブル205の内容を例示する図である。 メールゲートウェイ106の障害発生時のメール中継シーケンスを例示する図である。 メールゲートウェイ106の障害メール判定の処理フローを例示する図である。 メールゲートウェイ106の障害メール対応処理選択の処理フローを例示する図である。 メールゲートウェイ106の障害メール検出の処理フローを例示する図である。

まず、本実施例で定義する障害メールについて説明する。障害メールは、メールゲートウェイがそのメールを受信し特定の処理を行う過程において、プロセスダウンや、その特定の処理に時間がかかりすぎて他の処理に影響がでるような状態(以下、障害と呼ぶ)を発生させるメールと定義する。障害メールはメールゲートウェイが想定していないRFC不適合などのメールである場合が多いが、それ以外の、たとえば正常で悪意のないメールであっても、メールゲートウェイのプログラムに障害を発生させる場合がある。

障害メールは、実際にメールゲートウェイに、処理をさせて障害が起きないと検出できない。すなわち、一般的なスパムメールのように、メール自体に予め推測できるような特徴やそれを検出するアルゴリズムがあるわけではない。

また、スパムメールフィルタは、メール自体がスパムメールであるか否か判定するが、本実施例は、メールそのもので判定するのではなく、そのメールを受信したメールゲートウェイが障害を発生するか否かで判定し、判定した結果にもとづきメールゲートウェイの処理を変更する。

以下、本発明の実施例について図面を参照して説明する。

図1は、本実施例で想定するシステム構成の一例である。

この図において、符号101は通信端末、符号102は無線網、符号103はキャリア設備網、符号104はインターネットなどのネットワーク、符号105はメール転送サーバ、符号106はメールゲートウェイ、符号107はメールボックスサーバ、符号108は監視サーバである。

通信端末101は、携帯電話端末やＰＣ等のデータ通信可能な端末装置を示し、無線網102を介してキャリア設備網103と接続している。無線網102は、携帯電話キャリアが管理する無線ネットワークである。キャリア設備網103は、無線網102からの通信をインターネット104、メールゲートウェイ106およびメールボックスサーバ107へ中継するネットワークおよびネットワーク設備である。無線網102とキャリア設備網103は、本実施例のメールゲートウェイ106を管理する携帯電話キャリアによって管理される。

メール転送サーバ105は、MTA（Message Transfer Agent）とも呼ばれ、インターネット104を経由してメールゲートウェイ106とメールの送受信を行う。具体的には、メール転送サーバ105は、メール転送サーバ105を管理する他の携帯電話キャリアや他のプロバイダ内のメールをメールゲートウェイ106へ転送する処理と、メールゲートウェイ106から受信したメールを他の携帯電話キャリアや他のプロバイダ内へ中継する処理とを行う。

メールゲートウェイ106は、キャリア設備網103内に設置され、通信端末101またはメール転送サーバ105がキャリア設備網103へ送信したメールを受信し、メールの宛先がキャリア設備網103内であればメールボックスサーバ107へメールを中継し、メールの宛先がキャリア設備網103外（すなわち、他の携帯電話キャリアや他のプロバイダ内）であればメール転送サーバ105へメールを中継する。

なお、本実施例では、メールゲートウェイ106から見て、メールの送信元になる通信端末101またはメール転送サーバ105をまとめてメールクライアント110と表記し、メール転送サーバ105またはメールボックスサーバ107をメールの中継先とみなす場合はまとめて宛先メールサーバと表記し、メールゲートウェイ106、メールボックスサーバ107をメールクライアント110からメールを受信するサーバとみなす場合はメール受信サーバと表記する。

また、本実施例では、メールゲートウェイ106は複数台で負荷分散されており、メールゲートウェイ106aのように末尾にアルファベットを表記したものは、ひとつのサーバを示し、末尾になにもつかない場合は特にサーバを指定しないとする。

本実施例では、メールゲートウェイ106と通信端末101間、メールゲートウェイ106とメール転送サーバ105間の通信プロトコルはSMTPまたはESMTP(Extended SMTP)、メールゲートウェイ106とメールボックスサーバ107間のプロトコルはLMTP（Local Mail Transfer Protocol）を想定しているが、それ以外にも、HTTP(Hypertext Transfer Protocol)、IMAP（Internet Message Access Protocol）、POP（Post Office Protocol）、MMS（Multimedia Messaging Service）などのプロトコルが適用可能である。

メールボックスサーバ107はキャリア設備網103内に設置され、通信端末101宛てのメールを格納し、通信端末101へメールを配信する。携帯電話キャリアなどの大規模メールシステムでは、メールボックスサーバ107は大量のメールを格納するため複数台で構成するが、本実施例では簡略化のため1台のメールボックスサーバで説明する。本実施例では、通信端末101とメールボックスサーバ107間の通信プロトコルは限定しないが、実際にはIMAP、POP、MMS等を使用する。

監視サーバ108は、メールゲートウェイ106やメールボックスサーバ107から障害などのアラートを受信することにより、メールゲートウェイ106やメールボックスサーバ107を監視するサーバである。

図２は、メールゲートウェイ106を実現する情報処理装置のハードウェア構成である。

メールゲートウェイ106を実現する情報処理装置は、プロセッサ202と、記憶装置207と、キャリア設備網103にデータを送受信するための入出力回路インタフェイス203と、これらを接続するバスなどの内部通信線からなる。

記憶装置207は、半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。記憶装置207は、プログラム領域204と、データ記憶領域206とを格納している。プログラム領域204には、メールゲートウェイ106の機能を提供するプロセスを実現するプログラムが格納され、プロセッサ202により実行される。プログラムは、予めプログラム領域204に格納されていてもよいし、図示していない着脱可能な記憶媒体または通信媒体（すなわちネットワークまたはそれを伝播するデジタル信号や搬送波）を介して、プログラム領域204に導入されてもよい。データ記憶領域206には、プログラム領域204以外で利用される情報、たとえばプログラムの出力したログなどが格納される。

図３は、プログラム領域204に格納されている、メールゲートウェイ106で実行されるプロセスを実現するプログラムの構成である。

メールゲートウェイ106を実現するプログラムは、メール中継プロセスを実現するプログラム（説明の便宜のため、単に、メール中継プロセスという。以下、同様）312と、監視プロセス313と、他サーバ通信プロセス315と、共有データ316を含んで構成する。メール中継プロセス312は、メールの中継を担当する。監視プロセス313は、他のプロセスを監視し、他のプロセスの障害の検知や、障害を検知したときの処理等を担当する。他サーバ通信プロセス315は、N分散された他のメールゲートウェイ106との通信を担当する。なお、上記各プロセスは、プログラムの実行において、より細かい並行処理の実行単位であるスレッドで実現することも可能である。

共有データ316としては、各プロセスが処理するデータが格納され、上記プロセスのいずれかからでもアクセス可能に格納される。共有データ316は、障害メール情報テーブル321と、キュー322と、セッション処理情報323と、メール管理情報324と、メール325を含んで構成する。

障害メール情報テーブル321は、障害メールと判定されたメールの情報を記憶するテーブルであり、詳細は図４で説明する。

セッション情報323には、メールクライアント110やメールの宛先メールサーバ間との通信セッションを管理し、メール中継を実行するための情報を格納する。メール中継プロセス312は、複数のセッション処理情報323から、１つのセッション情報323を選択し、メールの中継処理を実行する。

セッション情報323は、メール中継プロセス312が現在、メールの受信処理と送信処理を行っている数と同じ数だけ存在する。

メール管理情報324には、メール中継プロセス312がメールを中継するための、メールに関する情報を、格納する。メール管理情報324とメール325は、1対1に対応する。

メール管理情報324は、メールのサイズ情報331と、メールの送信元情報332と、メールの宛先情報333と、処理フラグ情報334を含んで構成する。メールのサイズ情報331には、メール325のヘッダサイズとボディサイズを格納する。メールの送信元情報332には、メール325の送信元のメールアドレスや、メール325を送信した通信端末やサーバの情報を格納する。メールの宛先情報333には、メール325の宛先メールアドレスの情報を格納する。処理フラグ情報334には、メール中継プロセス312の行う処理をコントロールするための情報を格納する。メール中継プロセス312は、処理フラグ情報334によって、メール中継の正常処理とは異なる処理を行う。たとえばメール325を削除したり、障害の起こった処理をスキップしてメールの中継処理を継続したり、未達通知とよばれるメール（詳細は後述）を送信したりする。

図４は、障害メール情報テーブル321の構成の例を示す説明図である。

障害メール情報テーブル321は、障害メールと判定されたメールの特徴を抽出し、記憶し、以降に処理するメールが障害メールであるか判定するためテーブルである（判定方法は後述）。

メールの特徴とは、対象となるメールの一部分の文字列または全部でもよいし、対象部分をハッシュ関数などで計算した値（ハッシュ値）などでもよい。

障害メール情報テーブル321の各エントリは、管理ID401と、対象ヘッダ項目の判定情報402と、メールボディの判定情報403と、登録日時404と、送信元メールアドレス405と、送信元サーバの特定情報406と、宛先メールアドレス407と、サイズ408と、判定条件項目409、障害ポイント410、障害メール受信数411で構成する。

管理ID401は、障害メール情報テーブル321を管理するため、エントリごとに付与する識別子である。一つのエントリに対し各データが格納され、障害メール情報テーブル321が構成されている。メールゲートウェイ106が障害メール情報テーブル321の各エントリの情報を登録する方法の詳細は後述するため、ここでは各エントリの示す内容を説明する。

対象ヘッダ項目の判定情報402は、メールゲートウェイ106が障害メールを判定するための、メールヘッダの情報である。対象ヘッダ項目とは、受信したメールのメールヘッダ、またはメールボディの中のMIMEヘッダの中で、メールゲートウェイ106が、削除、または、追加、内容の書き換えなどの処理を行うヘッダ項目を示す。（以下、メールヘッダのヘッダ項目の削除、または、追加、内容の書き換えなどを行う処理をヘッダフィルタリングと呼ぶ）。対象ヘッダ項目の判定情報402とは、上記の対象ヘッダ項目の中で、メールゲートウェイ106が処理を行っていて障害が発生したヘッダ項目の特徴を抽出したものである。

対象ヘッダ項目の判定情報402にメールボディの中のMIMEヘッダが含まれる場合があるのは、MIMEヘッダは、メールボディにHTMLデータや画像ファイルなどの添付ファイルが含まれるときに使用され、メールゲートウェイ106がメールの添付について解析するメールヘッダの処理として、ボディのMIMEヘッダを解析するためである。

メールボディの判定情報403は、メールゲートウェイ106が障害メールを判定するための、メールボディの情報である。メールボディの判定情報403には、MIMEヘッダで区切られたMIME領域単位を、メールボディとして指定することも可能である。メールボディの判定情報403が、対象ヘッダ項目の判定情報402と別項目になっている理由は、メールゲートウェイ106のメールヘッダの処理と、メールボディの処理は異なり、障害の種類やシステムに与える影響が異なるためである。

登録日時404は、メールゲートウェイ106が、テーブル321に当該エントリを登録した日時である。メールゲートウェイ106は、登録日時404を起点にして、予め設定された有効時間の経過の有無により、エントリに格納された情報が有効か否かの判定を行う。また、エントリ数が、障害メール情報テーブル321に登録可能な数を超過した場合、登録日時404の古い順に削除する。

送信元メールアドレス405は、メールクライアント110のメールアドレスである。

送信元サーバ406は、メールゲートウェイ106が受信したメールの送信元のサーバのホスト名またはIPアドレスである。メールクライアント110が通信端末101の場合は、送信元サーバ406の項目は使用しない。

宛先メールアドレス407は、メールの宛先のメールアドレスであり、宛先が複数であっても記憶する。

サイズ408は、障害メールのヘッダとボディのサイズを示す。

判定条件項目409は、障害メールを判定するためにどの情報を使用するか、または組み合わせるかを決定する項目である。たとえば、メールゲートウェイ106がメールヘッダの処理中に障害を起こしたのであれば、対象ヘッダ項目の判定情報402を用いて障害メールの判定を行うべく“ヘッダ”登録を行い、メールゲートウェイ106がメールボディの処理中に障害を起こしたのであればメールボディの判定情報403を用いて判定行うべく“ボディ”を登録する。

同様に判定条件項目409 の“ボディサイズ”や“ヘッダサイズ”は、サイズ408の、障害の原因となったサイズを用いて障害メールの判定を行うことを意味する。メールゲートウェイ106のメールヘッダの処理とボディの処理の両方で障害が起きた場合、または区別がつかない場合は両方を記述する。すなわち、判定条件項目409には、ヘッダもしくはヘッダサイズ、および/または、ボディもしくはボディサイズを記録する。

障害ポイント410には、障害が発生した処理とプロセス（関数）を登録する。障害ポイント410は、メールゲートウェイ106が障害メールと判定したメールについて、障害の起こったポイントをスキップしてメール中継処理を継続する場合に使用する。障害ポイント410には、複数の処理で障害が起きた場合、または区別がつかない場合は複数の障害ポイントを登録することが可能である。

なお、409、410の項目に登録してある文字列は、実際にはメールゲートウェイ106で定義してある数値（ID）として記憶してもよい。たとえば409において、ヘッダは1、ボディは2といったように定義しておき、その値を登録してもよい。

障害メール受信数411は、このエントリに一致したメールを何回受信したかを示す値である。

図５は障害発生時のメールの中継のシーケンスを例示する図である。これは、メールゲートウェイ106がメールクライアント110から受信したメールを中継する処理で障害が発生したときのシーケンスを示す図である。

ここで、メールゲートウェイA106a、メールゲートウェイB106bは、それぞれ負荷分散できるように設置されている複数台あるメールゲートウェイ106の１台を示す。メールゲートウェイA106aが実行するステップのうち、障害メール検出513だけ監視プロセス313に実行され、それ以外の全てのステップはメール中継プロセス312により実行される。

最初に、メールクライアント110は、メール505をメールゲートウェイA106aへ送信する。メールゲートウェイA106aはメール505を受信すると、障害メールを判定する処理507（以下、障害メール判定と呼ぶ）を行う。障害メール判定507の時点ではまだ障害が発生していないため、メールゲートウェイ106は、メールの特徴などの抽出は行わない（詳細は図６で説明する）。

次に、メールゲートウェイA106aは、正常に受信したことを意味する正常応答509をメールクライアント110へ送信する。

次に、メールゲートウェイA106aは、前述したヘッダフィルタリング処理510を行う。ヘッダフィルタリング処理510において、メールゲートウェイA106aはメール505のメールヘッダのヘッダ項目の、削除、追加、内容の書き換えなどを行う。

次に、メールゲートウェイA106aはトランスコーディング処理511を行う。本実施例ではトランスコーディングは、メールのsubjectや本文に含まれる文字（絵文字を含む）の文字コードの変換を行うことと定義し、メールに添付されている画像、音声、動画等のデータの変換はトランスコーディングには含まない（メールに添付された画像ファイルの変換は、ステップ526の処理である）。トランスコーディング処理511において、メールゲートウェイA106aは、メール505の主にメールボディに含まれる絵文字を含む文字コードの変換を行う。

ここで、例としてトランスコーディング処理511で、メールゲートウェイA106aでメール中継プロセス312のプロセスダウン512が発生した場合を考える。この場合、メールゲートウェイA106aは障害メール検出処理513を行う。障害メール検出処理513とは、メールゲートウェイ106aが障害を起こしたメールを特定し、その特徴を取得し、障害メール情報テーブル321へ登録し、障害の起こった状況から復旧する処理である（詳細は図８で説明する）。障害メール検出処理513において、メールゲートウェイ106は障害を起こしたメールに対し、障害メール判定518という処理を行うが、ここでは図の簡略化のため省略し、ステップ518で詳細を説明する。

次に、メールゲートウェイA106aは、障害メール情報通知514をメールゲートウェイB106bへ送信する。障害メール情報通知514とは、負荷分散のために設置された他のメールゲートウェイ106へ障害メールの情報を通知する処理であり、他のメールゲートウェイ106全てに送信することが望ましい。

障害メール情報通知514を受信したメールゲートウェイB106bは障害メール情報テーブル更新する処理515を行う。

なお、障害メール情報通知514は、メールゲートウェイA106aが、障害メール情報通知514をＤＢサーバなどに登録し、他のメールゲートウェイ106がそのサーバから障害のメール情報を取得する方法でも実現可能である。

また、メールゲートウェイ106が1台しかなければ、障害メール情報通知514、障害メール情報テーブル更新処理515は省略する。

以下ステップ516から528までは、メールクライアント110が、メール505と同一のメール516をメールゲートウェイA106aまたはA106bへ送信した場合について示す。メールゲートウェイA106aはメール516を受信すると、障害メール判定518を行う。障害メール判定518において、メールゲートウェイ106は障害メール情報テーブル321に登録された特徴とメール516の特徴が一致するか判定し、一致した場合、判定結果に応じた処理を行う。メールゲートウェイA106aが障害メールと判定した後に行う処理は、本実施例では３種類、すなわち、エラー応答（ステップ519）、未達通知（ステップ521、522）、および障害ポイントのスキップ（ステップ523から528）から選択する（詳細は図７で説明する）。

障害メール判定518でエラー応答が選択された場合、メールゲートウェイA106aは、メール516の応答として、エラー応答519をメールクライアント110へ送信する。エラー応答519としては、回復困難エラー、たとえばSMTPでいうと500番台のエラーを、メールクライアント110へ送信する。

障害メール判定518で未達通知が選択された場合、メールゲートウェイA106aは、メール516の応答として正常応答521をメールクライアント110へ送信する。次に、メールゲートウェイA106aは、正常応答521とは異なるコネクション、つまりメールゲートウェイA106aからメールクライアント110へ新しいコネクションを確立してから、未達通知522をメールクライアント110へ送信する。未達通知522は、メール形式をとり、メール本文には、メールクライアント110のユーザが理解できる形式でエラーの内容を記述する。また、図示していないが、障害の状況により宛先メールサーバ111にも未達通知を送付してもよい。

図示していないが、エラー応答処理（ステップ519）、未達通知処理（ステップ521、522）の場合は、各処理が終了した場合、対象メールを削除する。削除する場合は、併せて、メールの情報をログとして、データ記憶領域206へ出力する。

障害メール判定518で障害の発生ポイントのスキップが選択された場合、正常応答523をメールクライアント110へ送信する。メールゲートウェイA106aはヘッダフィルタリング処理524を行う。次に、メールゲートウェイA106aは障害ポイントであるトランスコーディング処理をスキップする処理525を行う。ステップ525では、メール527の本文にエラーの内容、この場合であればトランスコーディング処理を行わなかったことを示す文言を加えてもよい。次に、メールゲートウェイA106aは画像ファイルの変換する処理526を行う。その後にメールゲートウェイA106aは、メール527を宛先メールサーバ111へ送信し、正常応答528を受信する。なお、本実施例のメールゲートウェイ106は、ステップ510と同じヘッダフィルタリング524、トランスコーディング、画像ファイルの変換526の各処理を行ってメールを中継しているが、それ以外の処理がステップ524から526の間に入ってもよい。

図６は障害メール判定507,または518の処理フローを示す図である。

障害メール判定（ステップ507、518）は、メールゲートウェイ106がメール受信時にそのメールが過去に障害を起こした障害メールであるか判定し、障害の再発を防止するための処理である。障害メール判定は、メール中継プロセス312により実行される。障害メール判定は、まず障害メール情報テーブル321の判定条件項目409にサイズ、ヘッダ、ボディの各検索キーで障害メールが登録されているかを調査し、登録されていれば該当する処理項目について特徴を抽出する、たとえばヘッダが記述されていれば受信した対象ヘッダの特徴を抽出する処理を開始する。つまり、メールゲートウェイ106は障害メール情報テーブル221に何も登録されていなければ、メールの各特徴を抽出する処理はしない。特徴の抽出とは、メールゲートウェイ106が対象となるメールの一部分の文字列または全部を抽出してもよいし、対象部分をハッシュ関数などで計算して値（ハッシュ値）を求めてもよい。以上が、図６の概要であり、詳細を以下で説明する。

ステップ601はメールサイズ（メールヘッダまたはメールボディのサイズ）が規定値（以下、この値をサイズ閾値と表記する）を超過かどうか調べる処理である。サイズ閾値とはメールゲートウェイ106が中継するメールヘッダまたはボディの大半がそのサイズ内に納まるサイズであり、あらかじめ定めておく。

判定条件項目409においてサイズと記述してあるエントリは、サイズ閾値を超過している場合であり、これは障害メール情報テーブル221を検索するのにボディサイズを検索キーとして検索するのが、他の項目、ヘッダやボディで検索するよりも処理の効率が良いためである。

したがって、ステップ601でメールゲートウェイ106はまずサイズ閾値超過であるかを調査し、ステップ604でメールヘッダ、ステップ607でボディの順で各項目を検索キーとして調査する。

ステップ601でメールサイズがサイズ閾値を超過していれば、ステップ602へ進む。もしメールサイズがサイズ閾値を超過していなければ、ステップ604へ進む。ステップ602は障害メール情報テーブル321の判定条件項目409にサイズの登録があるかどうか調べる処理である。もし障害メール情報テーブル321にサイズの登録あれば、ステップ603へ進み、サイズをキーにして障害メール情報テーブル321を検索し、検索結果と判定条件項目409の条件に一致する検索結果を記録してステップ604へ進む。

ステップ604は障害メール情報テーブル321の判定条件項目409にヘッダの登録があるか調べる処理である。もし障害メール情報テーブル321にヘッダの登録があれば、ステップ605へ進む。もし障害メール情報テーブル321にヘッダの登録がなければ、ステップ607へ進む。ステップ605は対象ヘッダの特徴を抽出する処理である。

障害メール情報テーブル321は判定条件項目409の各条件、すなわちヘッダ、ボディ、ヘッダサイズ、ボディサイズなどの条件がそれぞれ何件登録されているかを管理している。ステップ604では、障害メール情報テーブル321の判定条件項目409の値がゼロであれば登録がないと判定する。同様にステップ604、607でも障害メール情報テーブル321は判定条件項目409の各条件の登録数がゼロであることを調査する。

対象ヘッダの特徴抽出は、メールゲートウェイ106が処理するヘッダ項目を対象に特徴を抽出する処理である。メールヘッダには、送信日時を示すDateヘッダ項目、そのメールが中継されたサーバを示すReceivedヘッダ項目、そのメール特有のIDであるMessage-Idの項があるが、これらヘッダ項目はメールクライアント110が送信するたびに変わり、またメールゲートウェイ106はこれらのヘッダ項目は処理しないので、ステップ605ではこれらヘッダ項目を対象には含めない。メールゲートウェイ106が送信のたびに変化するヘッダ項目を一致条件にいれると、障害メールの判定をすり抜けて再度障害を起こす可能性があるためである。

また、メールゲートウェイ106のヘッダフィルタリング処理において、予めメールゲートウェイ106の設定ファイルに記述されているヘッダ項目を対象に処理を行うため、ヘッダフィルタリングが障害ポイントである場合は、メールゲートウェイ106は設定ファイルに記述されたヘッダ項目の特徴を抽出する。ステップ606は対象ヘッダ項目の特徴で障害メール情報テーブル321を検索する処理である。

ステップ607は障害メール情報テーブル321の判定条件項目409にボディが登録されているか調べる処理である。もし障害メール情報テーブル321にボディの登録あれば、ステップ608へ進む。もし障害メール情報テーブル321にボディの登録なければ、ステップ610へ進む。ステップ608はボディの特徴抽出する処理である。ステップ609は障害メール情報テーブル321をボディの特徴で検索する処理である。

ステップ610はステップ603、606、609で行った障害メール情報テーブル321の検索で、条件に一致したエントリが存在したか調べる処理である。もし条件に一致したエントリがなければ、障害メールでないと判定したことになり、障害メール判定を終了し、正常なメール中継処理を行う。

ステップ610で条件に一致したエントリがあれば、ステップ611へ進む。ステップ611は、一致したエントリから、登録日時304からの有効時間を超過しているエントリを除外する処理である。ステップ612は、同じく、送信元メールアドレス304が一致していないエントリを除外する処理である。

なお、ステップ612は、以前のステップで抽出した特徴と条件を組み合わせて、障害メールを判定する精度を上げるための処理であり、以前のステップで抽出した特徴と送信元メールアドレス以外の情報と組み合わせることも可能である。たとえば、メールゲートウェイ106が特徴をハッシュ値で管理していれば、異なるメールでもハッシュ値は同じになる可能性がある。そこで、ハッシュ値が同じでも送信元のメールアドレスが異なっているものを除くことで、メールを特定する確率を上げることができる。

ステップ613はステップ610と同様に、条件に一致したエントリがあるか調べる処理である。ステップ613で条件に一致したエントリがあれば、障害メールと判定する。もし条件に一致したエントリがなければ、障害メールではないと判定し、障害メール対応処理選択を終了する。ステップ613では、一致したエントリが複数ある場合も存在するが、その場合は障害メール対応判定615（詳細は図７）で説明する。

ステップ614は、ステップ613で条件に一致したエントリ数を障害メール受信数411に加算する処理である。

ステップ615から618は、対象メールを障害メールと判定した場合の処理である。ステップ615は障害メール対応処理選択処理である。障害メール対応処理選択処理は、メールゲートウェイ106が障害メール情報テーブル321の状況から、図５のエラー応答519、未達通知522、トランスコーディングのスキップ525の３種類の処理を選択する処理である。詳細は図７で説明する。ステップ615の結果がエラー応答であればステップ616へ進み、結果が未達通知であればステップ617へ進み、結果が障害ポイントスキップであればステップ618へ進む。

ステップ616ではメールゲートウェイ106がメールクライアント110へエラー応答を送信して、障害メール判定処理を終了する。ステップ617では、メールゲートウェイ106は障害メール判定を終了して、未達通知を送信する処理へ移行する。そして、メールゲートウェイ106は、図５に示す通り正常応答521と、正常応答とは異なるコネクションで未達通知522をメールクライアント110へ送信する。本実施例では記述していないが、障害の状況によりメールクライアント110への未達通知522だけではなく、宛先メールサーバ111にも未達通知を送付してもよい。

ステップ618、619は障害ポイントをスキップするケースであり、ステップ618ではメール本文に追加するエラー文言を選択する。これは、障害ポイントをスキップすることにより本来実行すべき処理を行っていないことをメールの受信者へ報告するための処理である。また、ステップ618で画像処理変換をスキップする場合、画像の代わりにエラーの文言や別の画像ファイルを挿入してもよい。ステップ619は、障害ポイントの情報をフラグとしてメール管理情報324にセットする処理であり、その後障害メール判定を終了する。

メールゲートウェイ106のメール中継プロセス312は、障害メール判定終了後、図５のステップ525の通り、障害ポイントをスキップする。メールゲートウェイ106のメール中継プロセス312は、メールを宛先メールサーバへ送信する前に、通常時はヘッダフィルタリング（510、524）、トランスコーディング（512）、画像ファイル変換（526）の３つの処理を行う。これらの処理は関数としてそれぞれ実装されている。それぞれの関数の入力と出力は他の関数の影響を受けないように、すなわち各関数を独立して実装できるように、設計する。たとえば、画像ファイル変換はヘッダフィルタリングやトランスコーディングの処理の実行の有無に関わらず、単独で実行することが可能なように、各関数を設計する。このように設計することにより、障害ポイントのスキップが可能になる。

メールゲートウェイ106がメールを送信する処理を行う各関数を呼び出す前に、メール管理情報324に障害ポイントのスキップ処理フラグのセットの有無を確認し、スキップ処理フラグがセットされていれば、その処理関数の呼び出しを省略して次の処理関数の呼び出しへ移行する。たとえば、トランスコーディングのスキップ（525）において、メールゲートウェイ106はメール管理情報324にトランスコーディングのスキップ処理がセットされているか確認し、セットされていればトランスコーディングの処理関数の呼び出しを省略して、次の画像ファイルの変換（526）の処理関数の呼び出しへ移行する。また、他の障害ポイントのスキップ方法として、各処理の関数内の最初のステップで、障害ポイントのスキップ処理フラグがセットされていれば、その関数の以降の処理を省略して次の処理関数へ移行する方法を採用しても良い。

図７は障害メール対応処理選択615の処理フローを示す図である。

これは、障害メール判定または障害メール検出（詳細は図８で示す）において、障害メールであると判定されたメールに対し、メールゲートウェイ106の対応方法を決定する場合の処理フローである。メールゲートウェイ106が判定する結果は、エラー応答、未達通知、障害ポイントのスキップの3種類である。

障害メール対応処理判定は、障害メールであるが受信者は通常のメールとして受信したいメール、すなわち悪意のない障害メールを受信したときに有効である。この場合、悪意の無いメールについては、メールゲートウェイ106が障害ポイントのスキップをして、送信できることが最も望ましい。たとえば、トランスコーディングが障害ポイントであれば、宛先メールサーバが信頼できる通信業者で、そこでトランスコーディングが行われれば、受信者に影響を与えず、メールゲートウェイ106は障害を回避できる。また、未達通知は障害の内容をメールとしてメールの送信者および/または受信者に通知することができる。エラー応答は、受信したメールの処理を拒否する処理であり、上記２つの処理を使用しない場合の処理となる。なお、図８で説明する障害メール検出処理のように、コネクションが切断されている場合は、メールの削除は行い、エラー応答の送信は省略してよい。

以下、図７を用いて障害メール対応処理判定の詳細を説明する。

ステップ701は、メールゲートウェイ106に予め設定された運用設定ファイルの条件に一致するか判定する処理である。上記運用設定ファイルには、障害メール情報テーブル321の各項目に対応する条件と、条件に一致したときにどの処理を選択するが記述されており、メールゲートウェイ106はその条件に一致する障害メールを運用設定ファイルに従った判定（ステップ710）を行う。

ステップ710の判定結果は、少なくとも、前述のエラー応答、未達通知、障害ポイントのスキップ、の3種類のいずれかになるが、運用設定ファイルに、前述の3種類以外の判定と、その判定結果独自の処理の記述を追加することも可能である。たとえば、前述の3種類のうち、未達通知と障害ポイントのスキップを組み合わせた判定となるよう記述を追加することも可能である。

上述のように、ステップ701と710により、障害メール対応処理判定のカスタマイズを可能にする。

ステップ702は、障害メール情報テーブル321のエントリが複数、またはエントリが１つだが障害ポイント410が複数記述されているか判定し、どちらかの条件に一致した場合、エラー応答（ステップ711）へ進む。

ステップ703は、障害メール受信数411が閾値を超過しているか判定し、超過している場合は、一般的なスパムメールのような大量配信のメールである場合が多いため、エラー応答（ステップ711）へ進む。

ステップ704では、障害ポイントがトランスコーディングであるか判定する。

ステップ705では、宛先メールアドレス407や受信したメールの文字コードがトランスコーディングを行わないで送信できる条件に一致する場合、障害ポイントのスキップ（ステップ712）に進む。

ステップ705,712を説明するために、宛先メールアドレスと文字コード、トランスコーディングの関係について述べる。メールゲートウェイ106が行うトランスコーディングは、宛先メールアドレス407により異なる。宛先メールアドレス407が、本実施例のメールゲートウェイ106を管理する携帯電話キャリアによって管理される無線網102とキャリア設備網103（自社網という）内であれば、当該携帯電話キャリアの通信端末でメールが正常に表示できるようにトランスコーディングを行う。

宛先メールアドレス407が、他携帯電話キャリアを含む通信事業者で管理され、メールの文字コードについて事前に取り決めを行っている場合、その通信業者向けのトランスコーディングを行う。たとえば、携帯電話キャリア固有の文字コードを持つ絵文字については、携帯電話キャリア間で相互にトランスコーディングを行う。ただし、事前の取り決めは、メールゲートウェイ106がトランスコーディングしなければならない場合と、メールゲートウェイ106がトランスコーディングすることが推奨である場合があり、後者の場合は後述するISO-2022-JPで送信してもよい。

宛先メールアドレス407が、上記以外の、事前に取り決めのない他携帯電話キャリアの場合、日本語環境のメール標準の文字コードであるISO-2022-JP（JIS）へトランスコーディングを行う。ただし、ISO-2022-JP（JIS）以外のメールの送信が禁止されているわけではなく、携帯電話以外のメールソフトはUnicodeのメールでも対応している場合が多い。

また、携帯電話キャリアによっては、メール受信時にトランスコーディングを行っている場合もあり、その場合はメールゲートウェイ106のトランスコーディングを行わなくても問題はない。

以上の背景に基づき、ステップ705では、メールゲートウェイ106がトランスコーディングを行わないで送信可能である条件を設定する。宛先メールアドレス407が、自社網ではない場合や、事前に取り決めを行っていて、トランスコーディングしたメールしか受け付けない通信事業者向けである場合は、NOと判定する。宛先メールアドレス407が上記以外である場合、受信したメールがISO-2022-JP（JIS）であれば、YESと判定とする。

また、宛先メールアドレス407がメール受信時にトランスコーディングを行っている通信事業者である場合も、YESと判定とする。また、宛先メールアドレス407が上記以外かつ、携帯電話キャリア以外であり、受信したメールがUnicodeであれば、YESと判定してもよい。

ステップ706は、障害ポイントが画像処理変換であるか判定し、画像処理変換であれば障害ポイントのスキップ（ステップ713）に進む。これは、画像処理変換できなくてもメールは送信可能であるためである。

ステップ707は、送信元サーバ406が携帯端末であるかを判定し、条件に一致した場合未達通知（ステップ714）へ進み、一致しなければエラー応答（ステップ709）へ進む。メールクライアント110が携帯端末であれば、携帯端末の仕様により異なるが、メールゲートウェイ106がエラー応答を送信しても、何の要因でメールの送信に失敗したか、不明または詳細がわからないことがある。そこで、ステップ707と714では、送信者が携帯端末であった場合はエラーの内容の詳細を記述できる未達通知を送信する。

図８は監視プロセス313の障害メール検出513の処理フローを示す図である。

メールゲートウェイ106に障害が起きたときに、その原因となった障害メールを突き止め、障害メールとプロセス、障害ポイントなどの情報を収集し、障害メール情報テーブル421に登録する処理を示す。

はじめに、監視プロセス313が障害、または、障害が発生したプロセスを検出する（ステップ801）。ステップ801において、監視プロセス313は、監視対象であるプロセスがダウンしたことを示すシグナルの発生や、プロセスの処理タイムアウトにより、障害を検出することができる。またステップ801は、監視対象であるプロセスが定期的に正常であることを示す情報を監視プロセス313に報告していて、監視プロセス313はその更新が停止したときに障害と検出する方法でも実現できる。

次に監視プロセス313は、障害の発生したセッション情報323を特定する（ステップ802）。ステップ802において、障害の発生したセッション情報323を特定する方法は、監視プロセス313がメール中継プロセス312の処理中のセッション情報323のポインタを保持する方法や、処理中のセッション情報323の番号などの識別子を保持する方法、メール中継プロセス312の処理中のセッション情報323のポインタや番号を共有データ316上に記録する方法などで実現する。

次に、監視プロセス313は、上記セッション情報323に対応するメール325を特定する（ステップ803）。ステップ804は上記セッション情報323に基づきどの処理、たとえばヘッダフィルタリング処理やトランスコーディング処理など、で障害が発生したか特定する処理である。ステップ805は処理内容から判定条件を特定する処理である。判定条件とは、後のステップ810において、障害メール情報テーブル321の判定条件項目409に格納する情報と同じであり、たとえばヘッダフィルタリングで障害があった場合は“ヘッダ”を選択し、トランスコーディングのボディで障害があった場合は“ボディ”を選択する。ステップ806は判定条件のサイズ、すなわち障害ポイントがヘッダであればヘッダサイズ、ボディであればボディサイズとして、それらがサイズ閾値を超過しているか調べる処理である。もし判定条件のサイズがサイズ閾値を超過であれば、判定条件にサイズを選択する（ステップ807）。

監視プロセス313がメール325から判定条件の特徴を抽出し（ステップ808）、メール325およびメール管理情報324から送信元メールアドレス、送信元サーバ、宛先メールアドレス、サイズなどを判定条件以外の情報を抽出する（ステップ809）。そして、ステップ810で監視プロセス313がステップ801から809まで取得した情報を障害メール情報テーブル321の各項目に登録する。

ステップ811は監視プロセス313が他サーバ通信プロセス315へ障害メール情報の転送を指示する処理であるが、メールゲートウェイ106が1台のときは行わない。ステップ812は、監視サーバ108へ障害が発生したことを通知するためのアラーム出力である。

ステップ814は、図7で説明した障害メール対応処理判定である。ステップ814でエラー応答の判定であった場合、監視プロセス313は、メール管理情報324に、実際に障害の発生原因となったメールの削除を行うための削除フラグをセットする（ステップ815）。削除フラグをセットされたメールは、ダウンしたプロセス、例ではメール中継プロセス312が復旧（ステップ820）した後に、復旧したメール中継プロセス312により削除される。ステップ815で、削除フラグをセットするのは、ステップ814の時点で既にメールゲートウェイ106とメールクライアント110間のコネクションは切断されているため、メールゲートウェイ106はエラー応答を返せないためである。

ステップ814で未達通知と判定された場合、監視プロセス313はメール管理情報324に未達通知を行うためのフラグをセットする（ステップ816）。ステップ814で障害ポイントのスキップと判定された場合、監視プロセス313はメール管理情報324に障害ポイントのスキップを行うためのフラグをセットする（ステップ817）。ステップ816、817でフラグをセットされたメールは、ステップ815同様にダウンしたプロセスが復旧（ステップ820）した後に処理が実行される。

そして、監視プロセス313は、ダウンしたプロセスが処理していたセッション情報323などを初期化し（ステップ819）、ダウンしたプロセスを再起動する（ステップ820）。

なお、本実施例では示していないが、メールゲートウェイ106はメールクライアント110から受信したメールをメモリやディスク上のキューに格納する場合がある。メールゲートウェイ106がメールをキューで管理すると、障害が発生して処理が中断しても、障害復旧後に復旧したプロセスがキューから再度メールを取出して処理を再開することがあり、障害が再発生することがある。その場合、図８の障害メール検出処理では、キューからメールを取り除く処理を追加することにより、障害の再発生を防止する。

なお、本実施例ではメールゲートウェイ106に本発明を適用した例を示したが、本実施例で解決できる、メールの受信により障害が発生する事象は、メールボックスサーバ107など、メール受信サーバなら全て発生する可能性がある。したがってメール受信サーバに本発明を適用し、同様の効果を得ることが可能である。

メールゲートウェイ106とメールボックスサーバ107の処理の相違は、メールゲートウェイ106が宛先メールサーバ111へメールを送信するのに対し、メールボックスサーバ107はメールをディスクなどの不揮発記憶領域へ書き込みすることである。したがって、メールボックスサーバ107に本実施例を適用する場合は、メールの送信部分の処理（図５のステップ527、528）を不揮発記憶領域への書込み処理に変更すればよい。

101：通信端末、102：無線網、103：キャリア設備網、104：インターネット、105：メール転送サーバ、106：メールゲートウェイ、107：メールボックスサーバ、108：監視サーバ、312：メール中継プロセス、313：監視プロセス、315：他サーバ通信プロセス、316：共有データ、321：障害メール情報テーブル、323：セッション情報、324：メール管理情報、325：メール、334：処理フラグ情報（未達通知、削除、障害ポイントスキップ）。

Claims (10)

1. メールクライアントからメールを受信し、中継するメールゲートウェイであって、
   中継処理中のメールを管理するための管理情報を備え、
   プログラムの実行により具現化される、
   メールの前記中継を担当するメール中継プロセスと、
   前記メール中継プロセスを監視する監視プロセスと、を含み、
   前記監視プロセスは、
   前記メール中継プロセスにおける障害の発生の有無を監視し、
   障害の発生を検知した場合には、前記管理情報を参照して、当該障害発生の原因となった障害メールの特徴と、当該障害が発生した障害ポイントと、を関連付けた情報を記録し、
   前記メール中継プロセスは、
   新たな処理対象メールについて、
   障害発生に係る前記記録されている情報を検索し、
   前記記録されている情報と一致する特徴を備える場合は、
   当該特徴に関連付けられた前記障害ポイントを回避するように、前記メール中継プロセスを変更する
   を特徴とするメールゲートウェイ。
2. 請求項１に記載のメールゲートウェイにおいて、
   前記メール中継プロセスは、入力と出力とが他の関数の影響を受けない関数として構成された処理をひとつ以上含み、
   前記監視プロセスは、
   前記障害ポイントとして、前記処理を特定する情報を記録し、
   前記メール中継プロセスは、前記メール中継プロセスの変更において、特定された前記処理をスキップする
   ことを特徴とするメールゲートウェイ。
3. 請求項２に記載のメールゲートウェイにおいて、
   前記記録された情報の項目に対応する条件と、当該条件に一致したときの処理として、処理の前記スキップと他の方法との組み合わせ、が記述された運用設定ファイルを備え、
   前記メール中継プロセスは、前記メール中継プロセスの変更において、前記運用設定ファイルに従った、処理方法を選択する
   ことを特徴とするメールゲートウェイ。
4. 請求項３に記載のメールゲートウェイにおいて、
   前記メール中継プロセスは、
   前記新たな処理対象メールについて、前記運用設定ファイルの記述と一致しない場合であって、かつ、複数の障害発生の原因として記録されているか、または、複数の障害ポイントでの障害が記録されている場合は、前記メールクライアントに、エラー応答または未達通知を送信し、
   上記エラー応答または未達通知の前記送信をしない場合に、障害を発生した処理が、トランスコーディングの場合、または、画像処理変換の場合は、当該処理での処理を省略し、
   処理での処理の前記省略をしない場合に、前記メールクライアントがあらかじめ定めた種類であれば、未達通知を送信し、それ以外の種類であれば、エラー応答を送信する
   ことを特徴とするメールゲートウェイ。
5. 請求項１から４のいずれか一に記載のメールゲートウェイにおいて、
   前記メール中継プロセスは、あらかじめ定めた方針に従った前記記録されている情報の検索において、ヘッダおよびボディのいずれか一方または両方の特徴が、前記記録されている障害メールの特徴と一致する場合は、前記新たな処理対象のメールが、前記記録されている情報と一致する特徴を備えると判定する
   ことを特徴とするメールゲートウェイ。
6. 請求項５に記載のメールゲートウェイにおいて、
   前記ヘッダおよびボディのいずれか一方または両方の特徴の一致とは、ヘッダおよびボディのいずれか一方または両方のサイズがあらかじめ定めた閾値を超えて、かつ、前記記録されている障害メールのサイズと一致することを含む
   ことを特徴とするメールゲートウェイ。
7. 請求項１から６のいずれか一に記載のメールゲートウェイにおいて、
   前記監視プロセスは、前記関連付けた情報の記録に際し、
   障害メールと判定されたメールの特徴を抽出し、
   前記障害ポイントとして、ヘッダおよびボディのいずれか一方または両方で障害が発生したのかと、障害が発生した処理と、を特定し、
   抽出した前記特徴と、特定した前記障害ポイントとを関連付けて、記録する
   ことを特徴とするメールゲートウェイ。
8. 請求項１から７のいずれか一に記載のメールゲートウェイにおいて、
   前記監視プロセスは、
   前記障害メールについて、前記障害に対する対応処理を決定し、
   前記障害を発生した前記メール中継プロセスの復旧処理を行った後に、前記対応処理を実行する
   ことを特徴とするメールゲートウェイ。
9. 請求項８に記載のメールゲートウェイにおいて、
   前記対応処理とは、前記障害メールの削除、または、前記障害が発生した処理の省略、であり、前記障害メールを削除する場合は、エラー応答、または、未達通知を、前記メールクライアントへ送信する
   ことを特徴とするメールゲートウェイ。
10. 請求項４に記載のメールゲートウェイにおいて、
    前記メール中継プロセスは、前記未達通知に、エラーの内容を含める
    ことを特徴とするメールゲートウェイ。

Images