JP5124527B2 - メール中継装置 - Google Patents

Description

本発明は、メールの中継方法に関する。

携帯電話の電子メールの普及により、携帯電話の通信サービスを提供している会社（携帯電話キャリアという）が管理するネットワーク（キャリア設備網という）およびメールサーバ群は大量のメールトラフィックを処理している。近年、画像ファイル、音声ファイルなどの添付ファイルによりメールサイズも巨大化し、今後、さらなるトラフィックの増大が見込まれている。以上のような背景により、携帯電話キャリアではメールサーバのストレージの容量とネットワーク負荷が問題となっている。

メールサーバのストレージの容量とネットワーク負荷を削減する方法として、特許文献１の方法がある。特許文献１には、送信側は、電子メールを送出する前に、圧縮された電子メールを受信側で解凍できるか否かを調査し、可能であればメール本体を圧縮し電子メールを送出する技術が開示されている。

以上の手法により、データ圧縮を行わずそのまま送信する電子メールシステムにおける問題点、すなわち、データ量が多い場合、通信費用が高く、また、通信回線が混雑するという問題点を解決しようとしている。

特開平８−３３１１７３号公報

特許文献１の方法は、たとえば添付ファイルが付加されているなど、メール本体のサイズが大きいメールに特に効果が大きいと考えられる。一般的にインターネット上で送信されているメールの本体は、Base64など7bitデータの形式に変換されている。このため、容量が元のデータの約1.3倍になっており、圧縮の効果が高いと考えられる。

しかしながら、特許文献１の技術を携帯電話キャリアのメールシステムに適用するには、端末に圧縮、伸張（または解凍。以下、伸張または解凍を復元という）に対応したメールプログラムをインストールする必要があり、実現は難しい。

通信端末に圧縮、復元に対応したメールプログラムをインストールせずにメールの圧縮、復元を行う方法として、メールを中継する中継装置を設置する方法が考えられる。すなわち、中継装置が、通信端末から受信したメールを圧縮してメールサーバへ中継し、メールサーバから取得した圧縮メールを復元して通信端末へ送信する方法である。

しかし、IMAPなどの、メールを取得するために携帯電話で使われるプロトコルでは、通信端末がメールを取得する前にメールサイズなどの情報を取得する処理が行われるため、中継装置で単純に圧縮または復元する方法では通信に不整合が発生し、メールを取得できない状況が発生する。

また、特許文献１は、メール本体は圧縮するが、宛先情報などを含む情報部は圧縮しない技術を開示している（段落００４０〜００４３）。しかしながら、携帯電話など、通信端末でやり取りされる短いメールは、メール本体よりもメールヘッダの容量が大きいものが大半であるため、メール本体だけの圧縮では効果が小さい。したがって、特許文献１に記載の方法では効果が小さい。

本発明では以上の課題を解決する中継装置と中継方法を提供する。すなわち、本発明は、通信端末への新たなプログラムのインストールを必要とせずに、携帯電話キャリアなどが備える大規模メールシステムにおける、ストレージ容量とキャリア設備網の負荷削減を可能にする中継装置を提供する。

本発明が提供する中継装置は、具体的には、キャリア設備網に設置され、メールの転送を行うSMTP（Simple Mail Transfer Protocol）通信とメールの取得を行うIMAP（Internet Message Access Protocol）通信を中継する。

具体的には、中継装置は、メール転送サーバからIMAPサーバに転送される通常のメールを受け取り、圧縮し、その圧縮前後のメールサイズや圧縮形式などの圧縮に係わる情報を圧縮後のメールに付加して、IMAPサーバ（メールボックス）に送信する。圧縮に際して、中継装置は、メール本体だけでなく、メールヘッダを含めて圧縮する。さらに、中継装置は、メールを圧縮したことで、IMAPの各種コマンドで不整合が発生しないように、元のメールヘッダに情報を付加したり、メールサイズなどのパラメータを変更したりする。

また、中継装置は、メール受信に関わる通信端末とIMAPサーバ間の通信を中継する。具体的には、中継装置は、通信端末から受信したエンベロープ情報取得要求や、メールサイズ取得要求や、メール取得要求をIMAPサーバへ中継する。また、IMAPサーバから受信した応答に基づいて、エンベロープ情報の作成、圧縮から復元後のメールサイズの計算、取得した圧縮メールの復元などを行うことによって、通信端末からの要求に対する応答を作成して、通信端末へ送信する。

より具体的には、メールを保管し、通信端末からの要求に応じて、通信端末をあて先とするメールを配信するメール管理サーバと、メール転送サーバと、通信端末と、に接続される中継装置において、メール転送サーバからメールを受信し、受信したメールについて、圧縮の効果が規定値を超えると判断すれば、メールを、メールボディとメールヘッダとを含めて圧縮して、圧縮メールのボディを作成し、圧縮に関わる圧縮情報と、メールヘッダに含まれる情報と、を含む圧縮メールのヘッダを作成し、圧縮メールのヘッダと圧縮メールのボディとを含む圧縮メールをメール管理サーバへ送信し、保管させ、圧縮の効果が規定値以下と判断すれば、受信したメールをメール管理サーバへ送信し、保管させることを特徴とする。

圧縮メールのヘッダを作成する際に、メールヘッダに含まれる情報から、圧縮メールのヘッダに含める情報を、Message-IDを含めて選択し、Message-IDに、圧縮メールのボディのサイズを、圧縮情報として追加してもよい。

また、通信端末から、メール管理サーバに保管されているメールに関わる要求を受信した場合は、要求を解析して、解析結果に応じて要求を変換し、メール管理サーバに、変換した要求を送信し、メール管理サーバから、変換した要求に対応する応答として、通信端末をあて先とするメールに関わる情報を受信し、解析結果と受信したメールに関わる情報とに基づき、通信端末から受信した要求に対する応答を作成し、作成した応答を通信端末に送信することを特徴とする。

受信したメールに関わる情報が圧縮メールであり、要求が、メールの取得要求、または、メールデータの一部を取得する要求、または、メールデータを解析する要求、であることを、解析結果が示していれば、圧縮メールに含まれる圧縮メールのボディから、メール転送サーバから受信したメールを復元し、復元したメールと、解析結果とに基づき、通信端末から受信した要求に対する応答を作成してもよい。

解析結果について、（あ）通信端末から受信した要求がメールサイズの取得要求を示していれば、IMAPコマンドのFetch allを選択し、（い）通信端末から受信した要求がメールデータの一部を取得または解析する要求を示していれば、メール全体を取得するIMAPコマンドのfetch rfc822を選択し、（う）上記（あ）（い）のいずれでもない場合は、通信端末から受信した要求を選択し、上記変換した要求としてもよい。

また、応答として受信した圧縮メールのヘッダに含まれる、メール管理サーバが追加したヘッダ項目を、復元したメールのメールヘッダに追加し、要求が、メールヘッダの取得コマンドであれば、項目が追加されたメールヘッダを抽出し、ボディ構造の取得コマンドであれば、メールのメールボディの構造を解析して、応答を作成することを特徴とする。

また、受信したメールに関わる情報が圧縮メールに関わる場合であり、通信端末からの要求に対する応答にメールサイズを含める必要があれば、受信した圧縮メールに関わる情報から圧縮情報を取得し、圧縮情報に基づき、圧縮前のメールサイズを計算し、通信端末への応答に含めることを特徴とする。

なお、メール転送サーバとIMAPサーバとの間には、一般的な中継装置が、設置されていることが多い。その場合には、すでに設置されている中継装置に、本発明が提供する機能を追加することにより、上記課題を解決することが可能になる。

また、本発明は、端末側に改造を加える必要が無いため、携帯端末に限定されること無く、通信端末一般に適用可能である。

本発明の中継装置によって大規模メールシステムにおいて、端末や、既存のサーバに改造を加えずに、ストレージ容量と、キャリア設備網のネットワーク負荷と、を削減可能になる。

本実施例を適用したシステムの構成を例示する図である。 本実施例を適用した中継装置106の構成を例示する図である。 メール格納シーケンスを例示する図である。 中継装置106が通信端末101から受信するメールデータの内容を例示する図である。 中継装置106がIMAPサーバ107へ送信するメールデータの内容を例示する図である。 IMAP通信シーケンスを例示する図である。 中継装置106がIMAPサーバ107から受信するメールデータの内容を例示する図である。 中継装置106のメール中継の処理フローを例示する図である。 中継装置106のIMAP中継の処理フローを例示する図である。 中継装置106のIMAPコマンド応答作成の処理フローの一例。

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

図1は、本発明で想定するシステム構成の一例である。この図において、符号101は通信端末、符号102は無線網、符号103はキャリア設備網、符号104はインターネットなどのネットワーク、符号105はメール転送サーバ、符号106は中継装置、符号107はIMAPサーバなどのメール管理サーバ（以下、IMAPサーバという）である。また、少なくとも、中継装置106とIMAPサーバ107とは、8ビットデータを扱うことが可能なネットワークで接続されるものとする。

通信端末101は、携帯電話端末やＰＣ等のデータ通信可能な端末装置を示し、無線網102を介してキャリア設備網103と接続している。無線網102は、携帯電話キャリアが管理する無線ネットワークである。キャリア設備網103は、無線網102からの通信をインターネット104、中継装置106およびIMAPサーバ107へ変換や中継するネットワークおよびネットワーク設備である。無線網102とキャリア設備網103は、本実施例の中継装置106を管理する携帯電話キャリアによって管理される。メール転送サーバ105は、MTA（Message Transfer Agent）とも呼ばれ、他の携帯電話キャリアなどからインターネット104を経由して受信したメールを、IMAPサーバ107を宛先として転送する。

本実施例では、インターネット104から、キャリア設備網103に属する通信端末101へメールが送信されるケースについて説明する。なお、キャリア設備網103に含まれる他の通信端末から通信端末101へメールが送信されるケース（キャリア設備網103内で送受信するケース）もあるが、その場合メール転送サーバがインターネット104ではなくキャリア設備網103に設置されるだけで、シーケンスはほとんど変わらないため、本実施例では省略している。

IMAPサーバ107はキャリア設備網103に設置され、通信端末101宛てのメールを格納し、IMAPで通信端末101へメールを配送する。キャリアなどの大規模メールシステムでは、IMAPサーバ107は大量のメールを格納するため複数台で構成するが、本実施例では簡略化のため1台のIMAPサーバで説明する。本実施例ではメールボックスをIMAPサーバとしているが、本発明はIMAPサーバ107の代わりにMMS（Multimedia Messaging Service）サーバであっても適用可能である。

中継装置106は、キャリア設備網103に設置され、メール転送サーバ105がキャリア設備網103へ送信したメールを受信し、IMAPサーバ107へ中継する。また、中継装置106はIMAPサーバ107と通信端末101間の一連のメール配信シーケンス（IMAP通信）も中継する。本実施例では、説明の簡略化のため、中継装置106が1台の場合を説明するが、メールトラフィックを負荷分散するために、複数台の中継装置106で構成してもよい。

また、一般的な大規模メールシステムにおいては、従来から、中継装置106をメールゲートウェイや機能的にMTA、MSA（Mail Submission Agent）などと呼ばれる中継装置106が設置されていることがある。本実施例も上記のケースを想定し、既存のメールを中継する機能に本実施例を実現する機能を加えた中継装置106でシステムを構成する。

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

記憶装置207は、半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。記憶装置207は、メール中継プログラムメモリ204とIMAP中継プログラムメモリ206とデータ記憶部205を格納している。メール中継プログラムメモリ204には、中継装置106がメール転送サーバ105からメールを受信し、IMAPサーバ107へ中継する処理を実現する各種制御プログラムが記録されている。IMAP中継プログラムメモリ206には、中継装置106がIMAPサーバ107と通信端末101間のIMAP通信を中継する処理を実現する各種制御プログラムが記録されている。上記の各プログラムは、プロセッサ202により実行される。また、各プログラムメモリ204、206には、各プログラムで利用するデータも格納される。

各プログラムは、予めプログラムメモリ204、206に格納されていてもよいし、図示していない着脱可能な記憶媒体または通信媒体（すなわちネットワークまたはそれを伝播するデジタル信号や搬送波）を介して、各プログラムメモリ204、206に導入されてもよい。データ記憶部205には、各プログラムメモリ204、206以外で利用される情報が格納される。

図3はメール格納シーケンスを例示する図である。これは、中継装置106がメール転送サーバ105から受信したメールをIMAPサーバ107へ格納するシーケンスを示す図である。本実施例では、メール格納をするプロトコルとして、SMTP、ESMTP(Extended SMTP)、LMTP（Local Mail Transfer Protocol）、HTTP(Hypertext Transfer Protocol)を想定しているが、その他メールデータを送信できるプロトコルであれば本実施例に適用可能である。

最初に、メール転送サーバ105は、メール304を中継装置106へ送信する。次に、中継装置106はメールの容量を削減するメールの圧縮・変換処理305を行う（以下、メール容量削減のためのメールの圧縮変換処理を単に圧縮変換または圧縮と呼ぶ。詳細については図8で示す）。次に、中継装置106は、圧縮・変換処理したメール308をIMAPサーバ107へ送信する。次に、IMAPサーバ107はメール格納する処理309を行う。次に、IMAPサーバ107は、正常応答310を中継装置106へ送信する。最後に、中継装置106は、着信通知311を通信端末101へ送信する。

図4は中継装置106がメール転送サーバ105から受信したメール304のデータの一例を示す図である。この図は、通信端末間で交換する一般的なメールデータの構成および内容であり、符号411はメールヘッダ、符号412はメールボディである。メールヘッダ411は、Return-Path401、Received402、Message-ID403、Message-Type404、Content-Type405、To406、From407、Date408、Subject409、Xで始まる拡張410などのヘッダ項目群から構成される。

Received402は、メール転送サーバなどメールを中継したサーバごとに付加されるヘッダ項目であり、メール転送サーバ毎に付加される。Message-ID403は、メールの発信元またはそのメールを中継したサーバがメールを一意に識別するための識別子である。To406とFrom407は、それぞれメールの発信元と宛先のメールアドレスを示す。Subject409は、メールの主題を示す。メールボディ412は、メール本文およびメールに添付したファイルなどから構成され、各々が、MIME（Multipurpose Internet Mail Extension）パートとして構成されている。一般的なメールでは、MIMEパートはBase64など7bitデータにエンコードされている。

図5は中継装置106がIMAPサーバ107へ送信するメール308のデータの一例を示す図である。この図において、符号501はメールヘッダ、符号509はメールボディである。メールヘッダ501の構成は、中継装置106が行う処理305により決定し、ここで示すヘッダ項目種別や処理方法は中継装置106の設定により変化する（詳細については図8で示す）。To406、From407、Date408、Subject409は、図4と同一であり、これら以外のヘッダ項目は中継装置106が処理305において変更または作成している。

Content-type502は、メールボディ509の圧縮形式を示す。Message-ID507は、Message-ID403の末尾に、中継装置106が受信したメール304と送信したメール308のそれぞれのメールサイズを示す情報（以下、メールサイズ情報と呼ぶ）が付加されたものである。ここでは、圧縮前のメール304が2600byteであり、圧縮後のメール308が900byteであることを示している。本実施例では、メールサイズ情報はIMAPのエンベロープと呼ばれる情報（詳細は図6で説明）に含まれているヘッダ項目であるMessage-IDに付加しているが、それ以外のヘッダ項目に付加してもよい。

なお、上記の中継装置106がヘッダに付加する情報は、必ずしも文字情報ではなく、データ量削減のためにバイナリ形式でも可能である。メールボディ509は、圧縮対象であるメール304のメールヘッダ411とメールボディ412とを纏めて圧縮したものである。

図6は、通信端末101が中継装置106を介してIMAPサーバ107とIMAPコマンドを交換するシーケンスを示す図である。なお、以下では、IMAPコマンドの表記は、同じ処理内容が複数のコマンドに含まれる場合は、当該処理内容を表すコマンド名を本実施例で定義し、複数のIMAPコマンドのうち代表的なものを括弧“（ ）”で表記する。たとえば、メールのサイズの取得という処理は、メールのサイズだけを取得するIMAPコマンドであるfetch rfc822.sizeや、fetch rfc822.sizeと、fetch flags、fetch internaldateという他の２コマンドを併せたコマンドであるfetch fastに含まれるため、この処理を示すコマンドを「メールサイズ取得要求（fetch rfc822.size）」と定義する。ただし、fetch rfc822.sizeは、fetch fast、fetch envelopeという2コマンドを合せたコマンドであるfetch all、fetch all、fetch bodyという2コマンドを併せたコマンドであるfetch fullにも含まれるが、これらは同時にfetch envelopeコマンドを含むため、後で説明するエンベロープ情報取得要求として定義する。また、一つのIMAPコマンドで表現できるコマンドは、そのコマンド名で記述する。

図6では、エンベロープ情報取得、メールサイズ取得、およびメール取得、の3種類のIMAPの処理シーケンスを説明する（これらのシーケンスは、連続して実行される必要は無く、それぞれ独立して実行することが可能である。

これらのシーケンスの前にIMAPサーバ107が通信端末101の認証（login）と、メールボックス選択(select)を行う必要があるが、図6では簡略化のため省略している。また、IMAPでは複数のメールに対する処理を１コマンドで行うことができるが、図6の各シーケンスは、このような場合も同様に処理する。

エンベロープ情報とは、IMAPで定義されているメールの構造を示す情報であり、Data、Subject、From、Sender、Reply-To、To、Cc、Bcc、In-Reply-To、Message-IDなどの、ヘッダ項目を含む。エンベロープ情報は、「エンベロープ情報取得」処理で、まとめて取得することができる。さらに、図5で説明したように、メールサイズ情報をMessage-IDなどヘッダ項目に付加することにより、エンベロープ情報取得に併せて、メールサイズ情報を取得することが出来て効率的である。

エンベロープ情報取得シーケンスを説明する。

エンベロープ情報取得シーケンスでは、最初に通信端末101は、エンベロープ情報取得要求）604を中継装置106へ送信する。エンベロープ情報取得要求が可能なコマンドとして、エンベロープ情報だけを取得するコマンドであるfetch envelope、や、fetch envelopeを含んだ複合コマンドであるfetch all、fetch fullがあるので、ここでは、上述の表記方法に従い、エンベロープ情報取得要求（fetch envelope）と表記する。

中継装置106は、エンベロープ情報取得要求(fetch envelope)605をIMAPサーバ107へ送信し、IMAPサーバ107は、応答として、エンベロープ情報606を中継装置106へ送信する。

中継装置106はエンベロープ情報606内のパラメータの変換処理607を行い（詳細は図9で示す）、変換エンベロープ情報608を生成する。

中継装置106は、変換エンベロープ情報608を通信端末101へ送信する。

メールサイズ取得シーケンスを説明する。

メールサイズ取得シーケンスでは、最初に通信端末101は、メールサイズ取得要求609を中継装置106へ送信する。メールサイズ取得要求が可能なコマンドとしてはfetch rfc822.sizeのほかに、fetch rfc822.sizeを含んだ複合コマンドであるfetch fastがあるが、エンベロープ情報取得要求に含まれるfetch all、fetch fullは含まない。ここでは、メールサイズ取得要求（fetch rfc822.size）609と表記する。中継装置106は、fetch all 610をIMAPサーバ107へ送信する。次に、IMAPサーバ107は、fetch all に対して、メールのエンベロープ情報とメールサイズ情報を含む応答611を中継装置106へ送信する。次に、中継装置106はfetch all の応答611に含まれるメールサイズ情報からメールサイズを計算する処理612を行う（詳細は図9で示す）。次に、中継装置106は、求めたメールサイズ613を通信端末101へ送信する。

メールの取得シーケンスでは、最初に通信端末101がメール取得要求614を中継装置106へ送信する。メール取得要求が可能なコマンドとしては、メールを取得するfetch rfc822のほかに、fetch rfc822を含んだ複合コマンドであるfetch allやfetch fastがあるので、ここでは、メール取得要求（fetch rfc822）614と表記する。中継装置106は、メール取得要求615をIMAPサーバ107へ送信し、IMAPサーバ107は、応答として、圧縮メール616を中継装置106へ送信する。中継装置106は、受信した圧縮メール616を復元する処理617を行う。最後に、中継装置106は、復元したメール618を通信端末101へ送信する。

なお、図6には記述していないが、メールの取得要求のように1通のメール全体を取得するのではなく、メールデータの一部を取得する要求がある。たとえば、メールヘッダのみの取得コマンド（fetch rfc822.header）や、メールデータを解析する要求、たとえばボディ構造の取得コマンド（fetch rfc822.body）などである。これらの要求に対する処理シーケンスは、メールの取得シーケンスと同様に、中継装置106が圧縮メール616全体を取得し、メールデータ復元617まで行い、その後復元したメールに対して追加の処理を行うことにより実現できる。

また、図6はIMAPコマンドについて説明しているが、MMSでもメールサイズの情報を変換するシーケンスを用いれば、IMAPの場合と同様に、本実施例の考え方を適用することができる。

図7は、中継装置106がIMAPサーバ107から受信した圧縮メール616のデータの一例を示す図である。圧縮メール616のデータは、メールヘッダ611、メールボディ709から構成する。メールヘッダ611のTo406、From407、Date408、Subject409、Message-ID507およびメールボディ709は、図5と同一であり、これら以外のヘッダ項目のうち、Content-Type502は、IMAPサーバ107がメール格納時の処理309、または圧縮メール送信616前の処理、のいずれかにおいて作成したヘッダ項目であり、Received710は、IMAPサーバ107が付加したヘッダ項目である。ただし、上記以外にもIMAPサーバ107が作成または変更したヘッダ項目はIMAPサーバ107の仕様により存在するが、ここでは省略する。

図8は、中継装置106がメール転送サーバ105からIMAPサーバ107へメールを中継するときの処理フローである（以下、中継装置106の一連の処理をメール中継処理と呼ぶ）。この処理フローは、図2に示すメール中継プログラムメモリ204中のプログラムを、プロセッサ202が実行することにより、実現される。

ステップ801は、中継装置106がメール転送サーバ105からメール304を受信する処理である。

ステップ802は、メール304のメールサイズが予め規定された値以下であるかかどうか調べる処理である。もしメールサイズが規定値以下であれば、圧縮の効果が少ないため、圧縮処理を省略してステップ819へ進み、もしメールサイズが規定値を超過していればステップ803へ進む。ステップ803は、メール304に未解析のヘッダ項目があるかどうか調べる処理である。もし未解析のヘッダ項目があれば、ステップ804へ進み、なければ、ステップ809へ進む。

ステップ804は、中継装置106が未解析ヘッダ項目を選択する処理であり、選択したヘッダ項目に対しステップ805から808の処理を行う。ステップ805は選択したヘッダ項目が必須ヘッダ項目であるかどうかを調べる処理であり、必須ヘッダ項目であればステップ806へ進み、必須ヘッダ項目でなければ、ステップ803へ戻る。

必須ヘッダ項目とは、中継装置106が圧縮したメール308のヘッダに付加するヘッダ項目であり、IMAPのエンベロープ情報や、SMTP、LMTP、ESTMPなどのプロトコル仕様、IMAPサーバ107の仕様等により必須と判断するヘッダ項目である。本実施例では、Date、Subject、From、Sender、To、Cc、Bcc、In-Reply-To、Message-IDなどIMAPのエンベロープ情報として必要なヘッダ項目を必須ヘッダ項目としている。図5の501に記述される項目が本実施例の必須ヘッダ項目である。

ステップ806は選択したヘッダ項目に回避対象文字があるかどうかを調べる処理であり、回避対象文字があればステップ807へ進み、なければステップ808へ進む。回避対象文字とは、以下に説明する通り、中継装置106が行うメール容量を削減する圧縮変換処理（具体的にはステップ812から816、詳細は後述）に不都合となる文字列である。

中継装置106は、圧縮変換処理において、中継装置106独自仕様の情報を圧縮情報としてメールヘッダに付加する。この独自仕様の情報が漏えいすると、メール転送サーバ105、通信端末101からのメールのヘッダ項目を改ざんし、IMAP管理サーバ107からメールを受信した中継装置106に、圧縮されていないメールであっても、圧縮メールであるかのように解釈させて、誤動作させ、システムに影響を与えることが可能になる。これを防ぐために、中継装置106が、IMAP管理サーバ107へ送信するためのメールを受信した時点で、既に付加されていた独自仕様の情報に該当する文字列に対して、回避処理を行う。

ステップ807は、中継装置106が、回避処理として、回避対象文字を特定の文字で囲んだり、他の文字に置換したりする処理である。

ステップ808は、選択したヘッダ項目を、圧縮メール308を作成するために、データ記憶部205にコピーする処理である。

ステップ809は、圧縮対象となるメールヘッダ411、メールボディ412のサイズを取得する処理である。

ステップ810は、メールボディ412にある添付ファイルの形式を解析する処理である。具体的にはMIMEヘッダの解析などを行い、メールに含まれる各MIMEパートのデータについて、文字列、画像、音声など種類の判別と、さらにそのデータの圧縮形式、およびそのデータのサイズの解析を行う。

ステップ811は、ステップ809、810の処理で取得したデータを元に、圧縮変換処理したときに見込まれる予想圧縮率が規定値以下かどうか調べる処理である。具体的には、ステップ809、810で取得したデータ群と各圧縮形式とサイズと、それらに対応した、中継装置106に予め設定されている予想圧縮率に基づいて、圧縮変換後の予想メールボディサイズを計算する。そして、予想メールボディサイズと受信メール304と比較し、予想圧縮率を計算する。予想メールボディサイズは、圧縮変換処理前の、簡易的な計算によるサイズの概算であり、正確な圧縮後のサイズはステップ812から816で計算する。

ステップ811において、予想圧縮率が規定値以下であればステップ819へ進み、予想圧縮率が規定値以下でなければステップ812へ進む。

ステップ812から816は、圧縮変換を実現するフローである。ステップ812は受信メール304を丸ごと圧縮してメールボディ509を作成する処理である。圧縮アルゴリズムは、ステップ810で取得したデータ形式と中継装置106の設定の組み合わせにより決定する。

なお、上述の通り、中継装置106とIMAPサーバ107とを接続するネットワークは、8ビットデータを扱うことが可能であるため、圧縮処理としては、Base64など7bitデータの形式に変換されているデータを元のデータ形式へデコードする処理であってもよい（このとき圧縮後のデータは圧縮前データの0.75倍になる）。

ステップ813は圧縮後のサイズを取得する処理である。ステップ814は、メールを圧縮した形式を含めたヘッダ項目Content-type502を作成する処理である。

ステップ815は、ステップ808でコピーした、選択したヘッダ項目を、新たなメールヘッダ501に追加する処理である。

ステップ816は、図5の説明で述べたとおり、Message-ID403に、圧縮前後のメールサイズ情報を付加して、Message-ID507を作成する処理である。

ステップ819は、メールヘッダ501とメールボディ509を含む圧縮メール308をIMAPサーバ107へ送信する処理である。

図9は、中継装置106が、通信端末101から受信したIMAPコマンドを解析して、IMAPサーバ107に送信するIMAPコマンドに変換して送信し、IMAPサーバ107から受信した応答から通信端末に送信する応答を作成する際の処理フローである。この処理フローは、プロセッサ202が、IMAP中継プログラムメモリ206中のプログラムを実行することにより、実現される。

本実施例では、中継装置106は、圧縮メールを作成する際に新たに圧縮ヘッダを作成し、IMAPサーバ107には、圧縮されているメールとされていないメールとの両方が格納される。これらのヘッダを正しく扱うために、中継装置106は、以下に説明するようにIMAPコマンドを変換する。

ステップ901は通信端末101からIMAPコマンド受信する処理である。ステップ902は受信したコマンドを解析する処理であり、メールサイズ取得要求（fetch rfc822.size）であればステップ903へ進み、メールデータの一部を取得または解析する要求、たとえばメールヘッダの取得コマンド（fetch rfc822.header）やボディ構造の取得コマンド（fetch rfc822.body）などの場合は、ステップ904へ進む。また、それ以外のコマンドの場合は、ステップ905へ進む。

ステップ903は、IMAPサーバ107へ送信するコマンドへの変換処理として、受信したメールサイズ取得要求（fetch rfc822.size）の代わりにfetch allを選択する処理である。ステップ904は、同様の変換処理として、受信したメールデータの一部を取得または解析する要求コマンドの代わりにメール全体を取得するfetch rfc822を選択する処理である。ステップ905は、変換処理として、受信したIMAPコマンドが前者のいずれでもない場合に、受信したコマンドそのものを、IMAPサーバ107へ送信するコマンドとして選択する処理である。

ステップ906は、中継装置106がステップ903、904、905でそれぞれ選択したIMAPコマンドをIMAPサーバ107へ送信し、応答待ち状態になる処理である。ステップ907はIMAPサーバ107からの応答を受信する処理である。この応答は、ステップ906で中継装置106が送信したコマンドに対する応答（以下、コマンド応答と呼ぶ）である。図9の処理フローは個々のIMAPコマンドに対して実行されるが、送信したIMAPコマンドと、コマンド応答とは、IMAPコマンドのタグと呼ばれる識別子により対応付けることが可能である。

ステップ911は、受信した応答が圧縮メールについてのコマンド応答であるかを判定する処理である。すなわち、対応するメールの中継処理においてメールを圧縮変換しなかった（例えば、図８のステップ811でYes）などの理由で、IMAPサーバ107には中継装置106により圧縮されたメールとそうでないメールが混在する。その場合に対応するためステップ911の処理が必要になる。ステップ911では、コマンド応答内に中継装置106が付加したメールサイズ情報の有無、またはContent-Type502により判定する。ステップ911において、圧縮メールである場合はステップ915へ進み、圧縮メールでない場合はステップ912に進む。

ステップ912は、通信端末101から受信しているコマンドとIMAPサーバ107からのコマンド応答とが対応しているか判定する処理であり、対応していれば、コマンド応答をそのまま、通信端末101への応答とすることができるので、ステップ918へ進み、対応していないと判定すればステップ913に進む。たとえば、図6において中継装置106が通信端末101からエンベロープ情報取得要求を受信し、IMAPサーバ107からエンベロープ情報を受信していれば対応していると判定し、通信端末101のメールサイズ取得要求に対してfetch allのコマンド応答を受信していれば対応していないと判定する。

ステップ913は、通信端末101から受信しているコマンドに合わせてコマンド応答を作成する処理である。たとえば、通信端末101のメールサイズ取得要求に対してfetch allのコマンド応答を受信していれば、fetch allの応答からメールサイズを取得し、メールサイズ取得要求のコマンド応答を作成する。

ステップ915は、IMAPサーバ107から受信したコマンド応答が、圧縮されていた場合に、中継装置106が通信端末101に送信するIMAPのコマンド応答を作成する処理（以下、IMAPコマンド応答作成処理と呼ぶ）である。IMAPコマンド応答作成処理の詳細は図10で説明する。ステップ918は、中継装置106が以上のステップ913、または915で作成したコマンド応答を通信端末101へ送信する処理である。

図10は、図9のステップ915に示す中継装置107によるIMAPコマンド応答作成処理の詳細フローであり、図9と同様に、プロセッサ202が、IMAP中継プログラムメモリ206中のプログラムを実行することにより、実現される。ステップ1008は既にステップ901で受信している通信端末101からのIMAPコマンドを解析する処理である。ただし、図9のステップ902における解析結果を参照してもよい。IMAPコマンドがエンベロープ情報要求であればステップ1009へ進み、メールサイズ取得要求であればステップ1031へ進み、メールの取得要求またはメールデータの一部を取得または解析する要求であればステップ1012に進み、これら以外の要求であればステップ1017に進む。

ステップ1009は、通信端末101から受信した、エンベロープ情報要求を含むIMAPコマンドがfetch envelopeであるかそれ以外、すなわちfetch allやfetch fullであるか判定する処理である。これらのいずれのIMAPコマンドに対する応答にもエンベロープ情報は含まれるが、IMAPコマンドがfetch envelopeの場合は、対するコマンド応答にはメールサイズを含めず、IMAPコマンドがfetch allやfetch fullなどの場合は対するコマンド応答にメールサイズを含める必要がある。したがって、IMAPコマンドがfetch envelopeである場合は、メールサイズを含める必要はないため、ステップ1014へ進み、それ以外の場合は、ステップ1021に進む。

ステップ1021は、IMAPサーバ107から受信したコマンド応答のエンベロープ情報のMessage-IDに含まれるメールサイズ情報から、圧縮後のメールサイズを取得する処理である。中継装置106がメール圧縮・変換処理を行っているため、コマンド応答に含まれるメールサイズと実際のメールサイズは、異なっている。そこで、ステップ1021から1023においてコマンド応答に含まれるメールサイズ情報から、実際のメールサイズを計算する処理を行う。ステップ1022は、コマンド応答に含まれるメールサイズからステップ1021の結果を減算し、IMAPサーバ107が付加したメールヘッダのサイズを計算する処理である。

ステップ1023は、メールサイズ情報中の圧縮前のメールサイズにステップ1022の結果、すなわち、復元後のメールサイズにIMAPサーバ107が付加したメールヘッダのサイズを加算する処理であり、通信端末101がメール取得要求により取得できる実際のメールのサイズを算出する。ステップ1014は、応答内のパラメータを変換する処理である。具体的には、Message-IDのメールサイズ情報を削除し、IMAPコマンドがfetch envelopeでない場合は、メールサイズをステップ1011で計算したメールサイズに置換する。

ステップ1031から1033は、ステップ1021から1023と同じ手順で、コマンド応答に含まれるメールサイズ情報から、実際のメールサイズを計算する処理を行う。ステップ1034は、ステップ1033で計算したメールサイズを用いて、メールサイズ取得要求のコマンド応答を作成する処理である。

ステップ1012は、コマンド応答内のメールボディを復元してメールを作成する処理である。このステップは、コマンド応答内のContent-type502によりメールの圧縮形式を判定し、ステップ812で圧縮されたメールの復元処理を行う。ステップ1013は、コマンド応答内のメールヘッダ内に含まれる必須ヘッダ項目以外のヘッダ項目をステップ1012で復元したメールのヘッダに追加する。ここで必須ヘッダ項目以外のヘッダ項目とは、IMAPサーバ107がメール格納時の処理309またはメールデータ送信616のいずれかにおいて作成したヘッダ項目であり、Received710などを指す。ステップ1015にて、既にステップ1008で解析したIMAPコマンドがメール取得要求であるかを判定し、メール取得要求であった場合は、更なる処理は行わず、それ以外、すなわちメールデータの一部を取得または解析する要求であった場合ステップ1016に進む。

ステップ1016は、復元したメールから取得すべき部分を抽出する、または解析して応答を作成する処理である。たとえば、メールヘッダの取得コマンド（fetch rfc822.header）の場合であれば、ステップ1013の処理が完了したメールからメールヘッダだけを抽出し、ボディ構造の取得コマンド（fetch rfc822.body）の場合はステップ1013の処理が完了したメールのメールボディの構造を解析して応答を作成する。

ステップ1017では受信したコマンド応答に更なる処理は行わず、ステップ1018ではコマンド応答に含まれるメールサイズ情報を削除する。

なお、本実施例において、中継装置106は、図8で示したメール中継処理の機能と、図9で示したIMAP中継処理を行う機能を両方備えるが、これらの機能の互いに異なる一方を実装した中継装置2台で本実施例と同じ効果を実現することができる。このとき、メール中継処理の機能を持つ装置はSMTP、ESMTP、LMTPなどメールを格納するプロトコル通信を中継し、IMAP中継装置はIMAP通信を中継する。

101：通信端末、103：キャリア設備網、105：メール転送サーバ、106：中継装置、107：IMAPサーバ、204：メール中継プログラムメモリ、205：データ記憶部、206：IMAP中継プログラムメモリ、411：メールヘッダ、412：メールボディ、501：メールヘッダ、509：メールボディ、611：応答、709：メールボディ。

Claims (10)

1. メールを保管し、通信端末からの要求に応じて、前記通信端末をあて先とするメールを配信するメール管理サーバと、メール転送サーバと、前記通信端末と、に接続される中継装置であって、
   前記メール転送サーバからメールを受信し、
   受信した前記メールについて、圧縮の効果が規定値を超えると判断すれば、前記メールを、メールボディとメールヘッダとを含めて圧縮して、圧縮メールのボディを作成し、
   前記圧縮に関わる圧縮情報と、前記メールヘッダに含まれる情報と、を含む圧縮メールのヘッダを作成し、
   前記圧縮メールのヘッダと前記圧縮メールのボディとを含む圧縮メールを前記メール管理サーバへ送信し、保管させ、
   前記圧縮の効果が規定値以下と判断すれば、受信した前記メールを前記メール管理サーバへ送信し、保管させる
   ことを特徴とする中継装置。
2. 請求項１に記載の中継装置であって、
   前記圧縮メールのヘッダを作成する際に、
   前記メールヘッダに含まれる情報から、前記圧縮メールのヘッダに含める情報を、Message-IDを含めて選択し、
   前記Message-IDに、前記圧縮メールのボディのサイズを、前記圧縮情報として追加する
   ことを特徴とする中継装置。
3. 請求項１または２に記載の中継装置であって、
   前記通信端末から、前記メール管理サーバに保管されているメールに関わる要求を受信し、
   前記要求を解析して、解析結果に応じて前記要求を変換し、
   前記メール管理サーバに、前記変換した要求を送信し、
   前記メール管理サーバから、前記変換した要求に対応する応答として、前記通信端末をあて先とする前記メールに関わる情報を受信する
   ことを特徴とする中継装置。
4. 請求項３に記載の中継装置であって、
   前記解析結果と受信した前記メールに関わる前記情報とに基づき、前記通信端末から受信した前記要求に対する応答を作成し、
   前記作成した応答を前記通信端末に送信する
   ことを特徴とする中継装置。
5. 請求項３または４に記載の中継装置であって、
   受信した前記メールに関わる前記情報が前記圧縮メールであり、
   前記要求が、メールの取得要求、または、メールデータの一部を取得する要求、または、メールデータを解析する要求、であることを、前記解析結果が示していれば、前記圧縮メールに含まれる前記圧縮メールのボディから、前記メール転送サーバから受信したメールを復元し、
   復元した前記メールと、前記解析結果とに基づき、前記通信端末から受信した前記要求に対する応答を作成する
   ことを特徴とする中継装置。
6. 請求項３ないし５いずれか一に記載の中継装置であって、
   前記解析結果について、
   （あ）前記通信端末から受信した前記要求がメールサイズの取得要求を示していれば、IMAPコマンドのFetch allを選択し、
   （い）前記通信端末から受信した前記要求がメールデータの一部を取得または解析する要求を示していれば、メール全体を取得するIMAPコマンドのfetch rfc822を選択し、
   （う）前記（あ）（い）のいずれでもない場合は、前記通信端末から受信した前記要求を選択し、
   前記選択した要求を、前記変換した要求として、前記メール管理サーバに送信する
   ことを特徴とする中継装置。
7. 請求項５に記載の中継装置であって、
   応答として受信した前記圧縮メールのヘッダに含まれる、前記メール管理サーバが追加したヘッダ項目を、復元した前記メールのメールヘッダに追加し、
   前記要求が、メールヘッダの取得コマンドであれば、項目が追加された前記メールヘッダを抽出し、ボディ構造の取得コマンドであれば、メールのメールボディの構造を解析して、前記応答を作成する
   ことを特徴とする中継装置。
8. 請求項３ないし７いずれか一に記載の中継装置であって、
   受信した前記メールに関わる前記情報が圧縮メールに関わる場合であり、
   前記通信端末からの前記要求に対する応答にメールサイズを含める必要があれば、受信した前記圧縮メールに関わる情報から前記圧縮情報を取得し、
   前記圧縮情報に基づき、圧縮前のメールサイズを計算し、前記通信端末への応答に含める
   ことを特徴とする中継装置。
9. 請求項３ないし７いずれか一に記載の中継装置であって、
   受信した前記メールに関わる前記情報が、圧縮されていないメールに関わる場合であり、前記通信端末からの前記要求に対する応答ではない場合、当該受信した前記メールに関わる前記情報に基づき、前記通信端末からの前記要求に対する応答を作成する
   ことを特徴とする中継装置。
10. 請求項１ないし９いずれか一に記載の中継装置であって、
    受信した前記メールのメールヘッダに、前記圧縮情報に含める文字列が予め含まれていた場合は、当該文字列に対して回避処理を行い、予め定めた他の文字列に置換するか、または、予め定めた特定文字で囲む
    ことを特徴とする中継装置。

Images