(57)【特許請求の範囲】
【請求項１】
電子メールを配送するメールサーバのためのプログラムであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部として、コンピュータを機能させ、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から、配送エラーの回数に応じて低い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするプログラム。
【請求項２】
電子メールを配送するメールサーバのためのプログラムであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部として、コンピュータを機能させ、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度か
ら高い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするプログラム。
【請求項３】
電子メールを配送するメールサーバのためのプログラムであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部として、コンピュータを機能させ、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から、配送エラーの回数に応じて高い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするプログラム。
【請求項４】
電子メールを配送するメールサーバであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部と、を含み、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から、配送エラーの回数に応じて低い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするメールサーバ。
【請求項５】
電子メールを配送するメールサーバであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部と、を含み、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から高い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするメールサーバ
。
【請求項６】
電子メールを配送するメールサーバであって、
電子メールを受信する処理を行う受信部と、
前記電子メールの優先度を決定する処理を行う優先度決定部と、
前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、
前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部と、を含み、
前記配送部が、
配送エラーと判定された電子メールについて、再配送する処理を行い、
前記優先度決定部が、
配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から、配送エラーの回数に応じて高い値に変更し、
前記配送部が、
優先度の高い電子メールを優先して配送する処理を行うことを特徴とするメールサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムに関する。
【背景技術】
【０００２】
従来から、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うメールサーバが存在する。
【０００３】
従来のメールサーバは、端末や他のメールサーバから送信された電子メールを受信した場合には、受信順にその電子メールを配送する処理を行っていた。従って、メールサイズの大きな電子メール、メールサイズの小さな電子メールの順に受信すると、メールサイズの小さな電子メールは、メールサイズの大きな電子メールの配送中、配送待ちとなってしまい、配送遅延が発生する。
【０００４】
例えば、従来のメールサーバの一例として特許文献１では、メールサイズの大きな電子メールのデータの一部が受信側で失われないようにするために、その電子メールを転送先アドレスに転送する処理を行うものがある（特許文献１の０００９、００１０段落を参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２６１９９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
通常、電子メールを作成した差出人や受信者は、その電子メールが受信者に即時伝達されることを期待しているが、上述したように、メールサイズの小さな電子メールであっても配送遅延が生じる場合があり、かかる場合、差出人や受信者の期待に応えることができない。
【０００７】
また、特許文献１に示すようなメールサーバでは、受信した電子メールが最大サイズを超えたか否かによって配送先のメールサーバを異ならせるようにしているが、メールサーバに電子メールを転送している間は、サイズの小さな電子メールは配送待ちの状態となってしまう。つまり、特許文献１に記載のメールサーバも、差出人の期待に反して電子メールの配送は遅延してしまう。
【０００８】
本発明は、上述した課題に鑑みたものであり、電子メールを配送するメールサーバにおいて、電子メールのサイズに基づく適切な順で電子メールを配送することが可能なメールサーバのプログラムを提供することにある。
【課題を解決するための手段】
【０００９】
（１）本発明は、電子メールを配送するメールサーバのためのプログラムであって、電子メールを受信する処理を行う受信部と、前記電子メールのサイズに基づいて、前記電子メールの優先度を決定する処理を行う優先度決定部と、前記電子メールの優先度に対応づけて、前記電子メールをスプール領域に格納する処理を行うスプール制御部と、前記優先度に基づき前記スプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う配送部として、コンピュータを機能させるプログラムに関する。
【００１０】
また、本発明は、上記プログラムを記憶した情報記憶媒体、上記各部として構成するメールサーバに関係する。本発明によれば、電子メールのサイズに基づく適切な順で電子メールを配送することができる。
【００１１】
（２）また、本発明のプログラムは、前記優先度決定部が、電子メールのサイズが大きいほど、電子メールの優先度を低くするように決定する処理を行い、前記配送部が、優先度の高い電子メールを優先して配送する処理を行うようにしてもよい。本発明によれば、サイズの小さい電子メールを優先して配送することができる。
【００１２】
（３）また、本発明のプログラムは、前記配送部が、配送エラーと判定された電子メールについて、再配送する処理を行い、前記優先度決定部が、配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から異なる値に変更するようにしてもよい。本発明によれば、配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から異なる値に変更するので、再配送の電子メールについて適切な順で電子メールを配送することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のネットワーク図の一例。
【図２】本実施形態のメールサーバの機能ブロック図の一例。
【図３】スプール領域に格納された電子メールの配送処理の説明図。
【図４】スプール領域に格納された電子メールの配送処理の説明図。
【図５】本実施形態の優先度を決定する処理のフローチャート図。
【図６】スプールディレクトリの説明図。
【図７】本実施形態の電子メールの配送処理のフローチャート図。
【図８】本実施形態の電子メールの配送処理を説明するための図。
【発明を実施するための形態】
【００１４】
以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
【００１５】
１．ネットワーク
図１は、本実施形態のネットワーク図の一例である。本実施形態のメールサーバ１０は、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うＭＴＡ（Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ａｇｅｎｔ）である。
【００１６】
メールサーバ１０は、配送処理に用いるエンベロープの宛先（宛先メールアドレス）及びエンベロープの差出元（差出元メールアドレス）、メッセージとからなる電子メールを受信し、ネットワークを介して受信した当該電子メールを、エンベロープの宛先に基づいて配送先メールサーバ（送信先メールサーバ）に配送する処理を行う。
【００１７】
より詳しく説明すると、メールサーバ１０は、ＭＵＡ（Ｍａｉｌ  Ｕｓｅｒ  Ａｇｅｎｔ）から送信された電子メールを受信する。なお、ＭＵＡとは、インターネット上の端末において電子メールを送受信するために使用されるクライアントプログラムである。次に、メールサーバ１０は、受信した電子メールのエンベロープの宛先のドメインを管理しているＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバや、メールサーバ１０のローカルエリア内のＤＮＳサーバ、或いは他のＤＮＳサーバに、受信した電子メールのエンベロープの宛先のドメインを問い合わせる（例えば、宛先のドメインのＭＸレコードを問い合わせる）。そして、ＤＮＳサーバの応答メッセージによって決められる配送先メールサーバへ、電子メールを配送（配信、送信、転送、リレー）する処理を行なう。
【００１８】
なお、本実施形態のメールサーバ１０が電子メールを受信するとは、ＳＭＴＰを通じて、端末から電子メールを受信する場合、ＳＭＴＰを通じて他のメールサーバから配送された電子メールを受信する場合を含む。
【００１９】
また、本実施形態のメールサーバ１０が電子メールを配送するとは、ＳＭＴＰを通じて、受信した電子メールを他のメールサーバに配送する処理や、メールサーバ１０が稼動する同一システム内にアカウントを持つユーザ宛に配送するためのローカル配信エージェントＭＤＡ（Ｍａｉｌ  Ｄｅｌｉｖｅｒｙ  Ａｇｅｎｔ）に配送する処理、ＭＤＡを介せずにメールサーバが稼動する同一システム内にアカウントを持つユーザ宛にローカル配送する処理を含む。
【００２０】
２．構成
図２は、本実施形態のメールサーバ１０の機能ブロック図の一例である。なお、本実施形態のメールサーバ１０は、図２の各部を全て含む必要はなく、その一部を省略した構成としてもよい。
【００２１】
記憶部１７０は、処理部１００などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などのハードウェアにより実現できる。
【００２２】
本実施形態の記憶部１７０には、スプール領域１７１を含む。このスプール領域１７１は、受信部１１１によって受信された電子メールを一時的に格納するための記憶領域である。なお、スプール領域１７１に記憶された電子メールは、配送処理が完了（配送正常終了あるいは配送エラー終了）すると、スプール領域１７１から削除される。なお、配送エラー終了の場合、つまり、配送先メールサーバに配送できない電子メールについては、再度、スプール領域１７１に格納される。
【００２３】
また、情報記憶媒体１８０は、コンピュータにより読み取り可能であり、この情報記憶媒体１８０にはプログラムやデータなどが格納されている。即ち、情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。つまり、処理部１００は、この情報記憶媒体１８０に格納されるプログラム（データ）から読み出されたデータに基づいて本実施形態の種々の処理を行うことができる。
【００２４】
例えば、情報記録媒体１８０は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）、メモリカード等である。
【００２５】
処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。なお、本実施形態の処理部１００が、情報記憶媒体１８０に格納されているプログラムやデータを読み出し、読み出したプログラムやデータを記憶部１７０に格納し、そのプログラムやデータに基づいて処理を行ってもよい。
【００２６】
処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。
【００２７】
処理部１００は、受信部１１１、優先度決定部１１２、配送予定時刻決定部１１３、スプール制御部１１４、配送部１１５とを含む。
【００２８】
受信部１１１は、端末（コンピュータ、携帯電話、タブレット型コンピュータ、スマートフォン）のＭＵＡによって、差出元から送信され、エンベロープの宛先が指定された電子メールを受信する処理（受け付ける処理）を行う。
【００２９】
また、優先度決定部１１２は、受信した電子メールの優先度（プライオリティ値）を決定する処理を行う。例えば、優先度決定部１１２は、電子メールのサイズに基づいて、電子メールの優先度を決定する処理を行う。なお、電子メールのサイズは、電子メールを構成するメッセージ全体のサイズである。つまり、電子メールのサイズは、電子メールを構成するヘッダ部のデータ、ボディ部のデータ、及び添付ファイルデータ（バイナリコードからテキストコードに変換された添付ファイルデータ）を含むデータ全体のサイズである。
【００３０】
本実施形態の優先度決定部１１２は、電子メールのサイズが大きいほど、電子メールの優先度を低くするように決定する処理を行う。例えば、電子メールのサイズをＳとし、優先度をＰとすると、Ｓ＜１メガバイトの場合はＰ＝５０（初期値）、１メガバイト≦Ｓ＜２メガバイトの場合はＰ＝４０、２メガバイト≦Ｓ＜３メガバイトの場合はＰ＝３０、３メガバイト≦Ｓ＜４メガバイトの場合はＰ＝２０、４メガバイト≦Ｓ＜５メガバイトの場合はＰ＝１０、５メガバイト≦Ｓの場合はＰ＝０に決定する。
【００３１】
なお、優先度決定部１１２は、配送エラーで再配送対象となった電子メールの優先度を、初期値（５０）より低い値に決定してもよい。つまり、優先度決定部１１２は、配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から異なる値に変更してもよい。
【００３２】
また、配送予定時刻決定部１１３は、受信した電子メールを配送する配送予定時刻（配送予定日時）を決定する処理を行う。また、配送予定時刻決定部１１３は、配送エラーで再配送対象となった電子メールの配送予定時刻を決定する処理を行う。例えば、配送エラー時点を基準に所定期間後（例えば、１０分後）を当該再配送対象となった電子メールの配送予定時刻として決定する。
【００３３】
また、スプール制御部（キュー管理部）１１４は、スプール領域１７１に、受信した電子メールを格納する（記憶する）処理を行う。例えば、スプール制御部１１４は、受信した電子メールと、当該電子メールの優先度と、当該電子メールの配送予定時刻とを対応づけて、スプール領域１７１に当該電子メールを記憶させる処理を行う。
【００３４】
なお、スプール制御部１１４は、配送部１１５によって配送処理が完了した電子メールをスプール領域１７１から削除する処理を行う。
【００３５】
また、配送部１１５は、スプール領域１７１に格納された電子メールを配送する処理を行う。例えば、配送部１１５は、配送予定時刻と現在時刻（現在日時、判断時）とを比較し、配送予定時刻が現在時刻よりも過去である（古い）電子メールについて配送する処理を行う。つまり、配送部１１５は、配送予定時刻が現在時刻より過去の時刻であるか否かを判断し、配送予定時刻が現在時刻より過去の時刻である電子メールを配送する処理を行う。
【００３６】
特に、本実施形態の配送部１１５は、優先度に従って電子メールを配送する処理を行う。つまり、配送部１１５は、優先度に基づきスプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う。
【００３７】
例えば、配送部１１５は、優先度の高い電子メールを優先して配送する処理を行う。つまり、優先度の降順（優先度の高い順）であって、配送予定時刻が現在時刻より過去の時刻である電子メールを配送する処理を行う。優先度が同位である電子メールが複数存在する場合には、配送予定時刻に従って電子メールを配送する処理を行う。つまり、優先度が同位である電子メールが複数存在する場合には、配送予定時刻の時系列（配送予定時刻の古いものから順）に、電子メールを配送する処理を行う。また、配送部１１５は、配送エラーと判定された電子メールについて、再配送する処理を行う。
【００３８】
３．従来のメールサーバの配送処理例
図３は、従来のメールサーバの配送処理を説明するための概念図である。図３に示すように、従来のメールサーバは、スプール領域１７１に電子メールを格納し、受信した順にスプール領域１７１に格納された電子メールを配送する処理を行う。
【００３９】
例えば、サイズが５メガバイトの電子メール３３を配送処理に長時間要する場合、電子メール３３より後に、格納された１メガバイト未満の小さな電子メール３４、３５・・・・７０は、配送待ちの状態となる。
【００４０】
つまり、従来のメールサーバは電子メール３３のサイズが大きいので、電子メールの３３の配送に時間を要し、その結果、サイズの小さな電子メール３４について配送遅延が発生してしまう。同様に、電子メール３４に続いて受信した電子メール３５、３６・・・・７０についても、連鎖的に配送遅延が生じてしまう。
【００４１】
４．本実施形態のメールサーバの配送処理の説明
（１）配送処理の概要
本実施形態のメールサーバ１０では、電子メールのサイズに基づいて、電子メールの優先度を決定する処理を行う。そして、優先度に基づきスプール領域に格納された電子メールの配送順を決定し、決定された配送順に従って電子メールを配送する処理を行う。このようにすれば、適切な順で電子メールを配送することができ、所定サイズ（例えば、１メガバイト）より小さい電子メールの配送遅延を、従来のメールサーバよりも軽減することができる。
【００４２】
図４は、本実施形態のメールサーバ１０の配送処理を説明するための概念図である。図４に示すように、メールサーバ１０は、スプール領域１７１に電子メールを格納し、サイズが所定サイズ（例えば、１メガバイト）より小さい電子メールは、サイズが所定サイズ以上の電子メールよりも優先して配送処理を行う。
【００４３】
例えば、メールサーバ１０は、５メガバイトのサイズを有する電子メール３３の後に、サイズが３キロバイトの電子メール３４を受信した場合には、電子メール３３より優先的に電子メール３４を配送する処理を行う。つまり、メールサーバ１０は、電子メールの受信順にかかわらず、スプール領域１７１に格納された所定サイズ未満の電子メール３４を、所定サイズ以上の電子メール３３よりも優先して配送する処理を行う。
【００４４】
そして、図４のＴ５１時点のように、スプール領域に電子メール３３よりも小さな電子メールが存在しなくなると、メールサーバ１０は、電子メール３３の配送処理を行うことになる。したがって、メールサーバ１０のスプール領域１７１に大量の電子メールが存在する場合には、所定サイズ未満の電子メールを優先して配送し（所定サイズ以上の電子メールを後回しにし）、その後、メールサーバ１０のスプール領域１７１に格納される電子メール数が少なくなれば、所定サイズ以上の電子メールを配送することができる。
【００４５】
つまり、電子メール３３は通信量が多いので電子メール３３の配送遅延が生じてしまうのは、差出人や受信者も納得するかもしれない。しかし、電子メール３３を起因として所定サイズ未満の電子メール３４、３５等が連動して遅延することになると差出人や受信者は、配信遅延による苛立ちやストレスを感じるおそれがある。
【００４６】
しかし、本実施形態によれば、所定サイズ未満の比較的小さな電子メールについて、配送遅延を生じさせないようにすることができるので、差出人や受信者共に、所定サイズ未満の小さな電子メールについてはストレスなく送受信することができる。以下、本実施形態のメールサーバ１０の処理について、さらに詳細に説明する。
【００４７】
（２）優先度を決定する処理
本実施形態のメールサーバ１０は、電子メールを受信すると、スプール領域１７１に格納する前にその電子メールの優先度を決定する処理を行う。
【００４８】
例えば、電子メールのサイズＳが１メガバイト（所定サイズの一例）よりも小さい場合（Ｓ＜１メガバイト）には、その電子メールの優先度を初期値（初期値＝５０）に決定する。
【００４９】
一方、電子メールのサイズＳが１メガバイト以上である場合には、初期値の優先度５０から、１メガバイト単位で１０減算する処理を行う。
【００５０】
つまり、本実施形態では、所定サイズ以上の電子メールは、そのメールサイズが１メガバイト単位で大きくなるにつれて、優先度を低くするようにして、優先度を決定する処理を行う。
【００５１】
具体的には、優先度Ｐは、下式（１）によって求めることができる。下式（１）は、電子メールのサイズをメガバイト単位で示した際の値をＳとしている（電子メールサイズＳの小数点以下は切り捨てる）。
【００５２】
Ｐ＝５０−（Ｓ×１０）・・・（１）
例えば、１．２メガバイトの電子メールの優先度Ｐは、５０−（１×１０）＝４０となる。また、２．４メガバイトの電子メールの優先度Ｐは、５０−（２×１０）＝３０となる。また、５．８メガバイトの電子メールの優先度Ｐは、５０−（５×１０）＝０となる。つまり、電子メールのサイズが大きくなるほど、電子メールの優先度を低くするようにして、優先度を決定する処理を行っている。
【００５３】
さらに、具体的に、図５を用いて、優先度決定の処理の流れについて説明する。まず、優先度に初期値（＝５０）を代入する（ステップＳ１）。次に、電子メールのサイズが所定サイズ（例えば、１メガバイト）より小さいか否かを判断する（ステップＳ２）。
【００５４】
そして、電子メールのサイズが所定サイズより小さい場合には（ステップＳ２のｙｅｓ）は処理を終了し、電子メールのサイズが所定サイズ以上である場合には（ステップＳ２のｎｏ）、メールサイズに基づき、優先度を計算する（ステップＳ３）。例えば、上述の式（１）によって、優先度を計算する。
【００５５】
そして、優先度が０より小さいか否か（優先度＜０）を判断する（ステップＳ４）。優先度が０より小さい場合（優先度が負の場合）には（ステップＳ４のｙｅｓ）、優先度に０を代入する。つまり、負の値にならないように優先度を０に設定する（ステップＳ５）。
【００５６】
そして、優先度が０以上である場合（ステップＳ４のｎｏ）、優先度が１００より大きいか否かを判断する（ステップＳ６）。優先度が１００より大きな場合には（ステップＳ６のｙｅｓ）、優先度に１００を代入する（ステップＳ７）。一方、優先度が１００以下である場合には（ステップＳ６のｎｏ）、処理を終了する。以上で処理が終了する。
【００５７】
（３）配送予定時刻
本実施形態のメールサーバ１０は、電子メールを受信すると、スプール領域１７１に格納する前に、配送予定時刻を決定する。つまり、スプール領域１７１に格納された各電子メールは、配送予定時刻に対応づけられていることになる。
【００５８】
例えば、メールサーバ１０は、電子メールを受信すると、受信時刻に基づきその電子メールの配送予定時刻を決定する。例えば、メールサーバ１０は、電子メールの受信時刻を基準に所定時間先（例えば、５秒先）の時刻を、その電子メールの配送予定時刻として設定してもよい。また、電子メールの受信時刻をその電子メールの配送予定時刻として設定してもよい。
【００５９】
（４）スプール制御
本実施形態のメールサーバ１０は、電子メールを受信すると、受信した電子メールをスプールファイルとして、記憶部１７０のスプール領域１７１において作成されたスプールディレクトリに格納する処理を行う。
【００６０】
ここで、スプール領域とは、受信した電子メールを一時的に格納するためのメモリ領域である。通常、コンピュータの処理速度よりも通信速度の方が極端に遅くなるため、一時的に、受信した電子メールをスプール領域に格納した後に電子メールの配送処理が開始される。言い換えると、スプール領域は、電子メールを一時的に格納するためのキュー領域である。
【００６１】
また、スプールファイルは、電子メールのことである。つまり、スプールファイルは、電子メールを構成するヘッダ部のデータ、ボディ部のデータとによって構成されるメッセージデータ全体を１つにまとめたファイルのことである。つまり、１つの電子メールにファイルが添付されている場合には、添付ファイルのデータを含むメッセージデータ全体を１つにまとめたファイルをスプールファイルとしている。なお、添付ファイルデータがバイナリデータである場合には、所定の文字コードでテキストデータに変換される。また、メッセージデータは、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）の規格に基づき作成される。
【００６２】
本実施形態では、図６（Ａ）に示すように、スプールディレクトリにおいて、優先度ディレクトリと配送予定時刻を示す年、月、日、時、分、秒の各ディレクトリとを階層的に作成し、作成された最下位の”秒”ディレクトリに、電子メールをスプールファイルとして格納する処理を行っている。
【００６３】
例えば、図６（Ｂ）に示すように、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／”ディレクトリをスプールディレクトリとして予め設定する。そして、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／”ディレクトリに、優先度が５０の”５０／”ディレクトリと、優先度が３０の”３０／”を作成する。優先度ディレクトリは予め作成してもよいし、優先度ディレクトリが存在しない場合にはスプール領域１７１に電子メールを格納する前に作成する。
【００６４】
そして、優先度ディレクトリの下位に配送予定時刻を示す年、月、日、時、分、秒の各ディレクトリを作成し、”秒”ディレクトリに、受信した電子メールをスプールファイルとして格納する処理を行う。
【００６５】
例えば、図６（Ｂ）に示すように、電子メール３４のスプールファイル名を「ｍａｉｌ３４」とし、電子メール３４の優先度が「５０」と決定され、電子メール３４の配送予定時刻が２０１０年６月１日１５時１分５秒すると、電子メール３４のスプールファイルｍａｉｌ３４は、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／５０／２０１０／６／１／１５／１／５／”ディレクトリに格納される。例えば、「優先度」や「配送予定時刻」が同じである電子メールが複数存在する場合には、同一のディレクトリに格納されることになる。
【００６６】
なお、本実施形態のメールサーバ１０は、受信した電子メールを、スプール領域１７１において、優先度と配送予定時刻とを示すディレクトリでスプール制御を行っているが、スプール領域１７１において、受信した電子メール（スプールファイル）と、優先度と、配送予定時刻とを対応づけてデータベース化してスプール制御を行ってもよい。
【００６７】
（５）配送処理
本実施形態のメールサーバ１０は、スプールディレクトリに格納されているスプールファイル（電子メール）のうち、最大配送件数（例えば、１００件）分、配送する処理を繰り返し行っている。そして、スプールファイルについて優先度の高い順であって、配送予定時刻が現在時刻（判断時刻）よりも過去のスプールファイルを配送する処理を行う。
【００６８】
より詳しく、図７を用いて具体的に説明すると、まず、最大配送件数に１回の検索で送信する件数を代入する（ステップＳ１０）。例えば、１回の検索で最大１００件配送する場合には、最大配送件数＝１００となる。また、配送処理数に初期値（０）を代入する。
【００６９】
そして、スプールディレクトリ内のディレクトリ名”数値”を検索する処理を行う（ステップＳ１１）。例えば、スプールディレクトリが”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／”である場合には、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／”ディレクトリにおいて、”数値”の名前であるディレクトリを検索する。すなわち、本実施形態では、”優先度”を数値で表しているため、検索結果は、”優先度”の名前が付されたディレクトリを検索することになる。
【００７０】
例えば、図６（Ｂ）に示すように、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／”ディレクトリにおいて、ディレクトリ”５０”、”３０”が存在する場合には、ディレクトリ”５０”、”３０”が検索される。
【００７１】
次に、優先度の高い順、（ステップＳ１２）であって、優先度ディレクトリの”年／月／日／時／分／秒／”ディレクトリにおいて、”年／月／日／時／分／秒／”で特定される配送予定時刻が現在時刻より古い”秒”ディレクトリ（ステップＳ１３）について、”秒”ディレクトリ内のスプールファイルについて配送処理を行う。またスプールファイルの配送処理を行う度に、配送処理数をカウントする（ステップＳ１４）。
【００７２】
つまり、優先度ディレクトリの降順に（優先度が高いものから順に）、優先度ディレクトリの、”年／月／日／時／分／秒／”の各ディレクトリ名で特定される配送予定時刻が現在時刻より古いスプールファイルについて繰り返し配送処理を行う。（ステップＳ１２〜ステップＳ１８）。つまり、配送予定時刻が現在時刻よりも未来の日時である場合には、配送予定時刻の”年／月／日／時／分／秒／”ディレクトリにあるスプールファイルについては配送処理を行わない。
【００７３】
例えば、ステップＳ１３において、優先度５０のディレクトリであって配送予定時刻が古いか否かを判断する時刻（現在時刻、判断時）が、図６（Ｂ）に示す２０１０年６月１日１５時１分１０秒である場合には、”／ｖａｒ／ｓｐｏｏｌ／ｍａｉｌ／５０／”ディレクトリの”２０１０／６／１／１５／１／５／”ディレクトリと、”２０１０／６／１／１５／１／６／”ディレクトリにあるスプールファイルｍａｉｌ３４、ｍａｉｌ３５を配送する処理を行う。
【００７４】
そして、優先度５０のディレクトリあって、配送予定時刻が現在時刻より古いスプールファイルについて配送処理が完了すると、その後、優先度３０のディレクトリであって、配送予定時刻が現在時刻より古いスプールファイルを配送する。例えば、”２０１０／６／１／１５／１／１”ディレクトリにあるスプールファイルｍａｉｌ３３について配送処理を行う。
【００７５】
優先度が同位であって現在時刻よりも古い配送予定時刻のディレクトリが複数存在する場合には、ランダムな順にディレクトリにあるスプールファイルを配送するようにしてもよいし、配送予定時刻の時系列（古い順）にスプールファイルを配送するようにしてもよい。
【００７６】
なお、本実施形態のメールサーバ１０は、配送先メールサーバと、複数の通信（セッション）を確立させて、同時に複数のスプールファイルを並列に配送先のメールサーバに配送するようにしてもよい。また、メールサーバ１０は、複数の配送先サーバそれぞれと、通信を確立させて、並列に各配送先メールサーバに電子メールを配送するようにしてもよい。
【００７７】
また、一旦、配送先のメールサーバとのセッションが確立して配送処理が開始された電子メールは、その電子メールの配送処理が完了（正常終了、或いはエラー終了）するまで中断することはない。したがって、配送処理が開始された電子メールが後回しになることはない。
【００７８】
また、本実施形態のメールサーバ１０は、配送処理が完了（正常終了、或いは、エラー終了）したスプールファイルを、スプール領域１７１から削除（消去）する処理を行う。なお、配送処理がエラー終了したスプールファイル（電子メール）は、エラー終了時点に基づき決定される配送予定時刻と優先度を決定してディレクトリを作成し、作成されたディレクトリに格納する。
【００７９】
なお、スプールファイルを削除する前に、そのスプールファイルを、記憶部１７０のスプール領域１７１とは異なる記憶領域、或いは、他のコンピュータ（保存用のサーバ）の記憶領域に格納するようにしてもよい。
【００８０】
本実施形態のメールサーバ１０は、このように、ステップＳ１２〜Ｓ１８によるループ（繰り返しの処理）、ステップＳ１３〜Ｓ１７によるループを行うが、”秒”ディレクトリ内のスプールファイルについての配送処理後、配送処理数が最大配送件数を超えたか否かを判断する（ステップＳ１５）。つまり、本実施形態では、配送処理を行う度に配送処理数をカウントし（ステップＳ１４）、カウントされた配送処理数が最大配送件数を超えた場合には、（ステップＳ１５のｙｅｓ）、ループを中断し処理を終了する（ステップＳ１６）。一方、配送処理数が最大配送件数を超えていない場合には（ステップＳ１５のｎｏ）、次の”秒”ディレクトリの配送処理を行う。
【００８１】
以上で、処理が終了する。本実施形態のメールサーバ１０は、常駐型サーバであるので、１回の検索での配送処理が終了すると、スタートに戻り、図７の処理を繰り返し行う。
【００８２】
以上より、本実施形態によれば、メールサイズが所定サイズ（例えば、１メガバイト）より小さい電子メールが優先して配送され、所定サイズ以上の電子メールについては後回しに配送されるので、少なくとも所定サイズより小さい電子メールについては配送遅延を生じさせないようにすることができる。
【００８３】
また、所定サイズ以上の電子メールについて配送処理を行う場合には、スプール領域１７１に格納されている電子メール数（スプールファイル数）が少なくなるので、所定サイズ以上の電子メールの配送処理を起因に発生する所定サイズ未満の電子メールの配送遅延を最小限に抑えることができる。
【００８４】
つまり、本実施形態のメールサーバ１０によれば、図８に示すように、Ｔ１００〜Ｔ１０３にかけて優先度５０、４０、３０それぞれの電子メールがスプール領域１７１に格納されていた場合、Ｎ回目の検索、Ｎ＋１回目の検索、Ｎ＋２回目の検索のいずれも、まず優先度が５０の電子メールの配送を優先的に行う。
【００８５】
例えば、Ｎ回目、Ｎ＋１回目の検索では、優先度５０の配送処理数が最大配送件数を超えてしまい、優先度４０、３０の配送ができない状況にあるといえる。しかしながら、所定サイズ未満の電子メールの配送を速やかに行うことができる。
【００８６】
そして、Ｎ＋２回目の検索では、優先度５０の配送処理が終了した時点で配送処理数が最大配送件数を超えておらず優先度４０の配送処理が開始され、さらに、優先度４０の配送処理が終了した時点で配送処理数が最大配送件数を超えておらず優先度３０の配送処理が開始されることになる。つまり、Ｎ＋２回目の検索では、所定サイズ未満の電子メール数が少なくなり、所定サイズ未満の電子メールの配送後、所定サイズ以上の電子メールの配送処理が開始されることになる。したがって、所定サイズ以上の電子メールの配送処理を起因に発生する所定サイズ未満の電子メールの配送遅延を最小限に抑えることができる。
【００８７】
（６）再配送処理
本実施形態のメールサーバ１０は、配送処理を行った電子メールの配送がエラーであった場合には、その電子メールについて配送エラー時点を基準に所定期間後に再配送する。そこで、本実施形態では、再配送の対象の電子メールの優先度を下げるようにしてもよい。つまり、メールサーバ１０は、配送エラーと判定された電子メールについて、再配送する処理を行う場合には、配送エラーと判定された電子メールの優先度を、当該電子メールの初回配送の優先度から異なる値に変更するようにしてもよい。
【００８８】
例えば、電子メール７０の配送処理結果がエラーである場合には、メールサイズに基づき決定される優先度値から更に１０減算し、減算した値を最終的な電子メール７０の優先度に決定する。具体的には、電子メール７０の初回配送時の優先度を５０に決定し、電子メール７０の初回配送がエラーであったとすると、電子メール７０の優先度を５０から４０に変更する。そして、電子メール７０の配送予定時刻を、エラー終了時点から１０分後の時点に決定する。そして、決定された優先度と配送予定時刻に基づきディレクトリを作成し、作成されたディレクトリに電子メール７０を格納する。
【００８９】
このようにすれば、初回配送の電子メール（再配送でない電子メール）を、再配送する電子メールに対して優先して配送することができる。通常、再配送の対象となる電子メールは、再度エラー結果になることがあり、かかる場合には処理時間が長くなる傾向、処理負荷が高くなる傾向にある。したがって、初回配送の電子メールを優先して配送し、再配送の電子メールを後回しにすることで結果的に遅延防止を図ることができる。
【００９０】
なお、本実施形態のメールサーバ１０は、メールサイズにかかわらず、配送エラー回数に基づいて、優先度を決定してもよい。例えば、初回時は優先度を５０に決定し、１回目のエラー時は優先度を４０に決定し、２回目のエラー時は優先度を３０に決定し、というように、配送エラー回数（再配送回数）が増加するにしたがって、優先度を下げるように決定してもよい。
【００９１】
また、本実施形態のメールサーバ１０は、メールサイズに基づき優先度を決定し、当該優先度から、配送エラー回数に応じた値を減算してもよい。例えば、図５のフローチャートに従って優先度を決定し、当該優先度から配送エラー回数に応じた値を減算する。例えば、初回配送時の優先度が３０である場合、１回目の配送エラーが生じた場合には、優先度から所定値１０減算する。つまり、再配送時の優先度は２０になる。そして、２回目の配送エラーが生じた場合には、さらに優先度から所定値１０を減算する。つまり、再々配送時の優先度は１０になる。なお、繰り返し配送エラーになると優先度が負の値になる場合があるが、かかる場合には優先度を強制的に０に決定するようにしてもよい。
【００９２】
（７）設定処理について
本実施形態でのメールサーバ１０は、ユーザ（管理者）の入力情報に基づいて、メールサイズの大小の判断基準となる「所定サイズ」を設定する設定部を含んでいてもよい。また、設定部は、ユーザの入力情報に基づいて、優先度の「初期値」を設定するようにしてもよい。
【００９３】
また、本実施形態では、「１メガバイト」単位で、優先度の変動幅（下げ幅）を「１０」にする例について説明したが、本実施形態のメールサーバ１０の設定部は、ユーザの入力情報に基づいて、優先度の変動幅を制御するための電子メールの「サイズ単位」、及び、「変動幅」を設定するようにしてもよい。
【００９４】
例えば、ユーザの入力情報に基づき、「所定サイズ」を「３メガバイト」に設定し、優先度の「初期値」を「５０」に設定し、「サイズ単位」を「２メガバイト」に設定し、「変動幅」を「５」に設定した場合には、サイズが３メガバイト未満の電子メールについての優先度は初期値（５０）に決定し、サイズが３メガバイト以上〜５メガバイト未満の電子メールについての優先度は４５に決定し、サイズが５メガバイト以上〜７メガバイト未満の電子メールについての優先度は４０に決定することになる。
【００９５】
また、本実施形態では、ユーザの入力情報に基づいて、１回の検索で配送する上限となる「最大配送件数」を設定できるようにしてもよい。
【００９６】
このようにすれば、管理者が電子メールの配送遅延を生じさせないようなメールサーバ１０の設定を適切に行うことができる。
【００９７】
５．変形例
（１）優先度に基づく配送処理について
本実施形態では、電子メールのサイズが大きいほど、優先して配送するようにしてもよい。つまり、所定サイズ（例えば１メガバイト）以上の電子メールを、所定サイズ未満の電子メールよりも優先して配送してもよい。かかる場合には、優先度の決定処理を変形する、或いは、電子メールの配送順を優先度の昇順（優先度の低いものから順）にする。
【００９８】
例えば、優先度の決定処理を変形する場合には、所定サイズ（例えば１メガバイト）以上の電子メールは、所定サイズ未満の電子メールよりも優先度を高くする。そして、そのメールサイズが１メガバイト単位で大きくなる程、優先度が高くなるようにして、優先度を決定する処理を行うようにしてもよい。
【００９９】
このようにすれば、メールサイズの大きなものを優先して配送したいという要望のある環境下においては、適切な順に電子メールを配送することができる。
【０１００】
また、本実施形態では、初回配送の電子メールを、再配送の電子メールよりも優先して配送する例について説明したが、再配送の電子メールを初回配送の電子メールよりも優先して配送するようにしてもよい。かかる場合には、優先度の決定処理を変形する、或いは電子メールの配送順を優先度の昇順（優先度の低いものから順）にする。
【０１０１】
例えば、優先度の決定処理を変形する場合には、電子メールの配送処理結果がエラーである場合には、配送エラー回数に応じて優先度が高くなるように優先度を決定する。例えば、配送エラー回数の増加にしたがって、優先度を１０上げる（例えば、初回配送時の優先度が５０である場合に配送エラーが生じた場合、その優先度を５０から６０に上げる）ようにしてもよい。なお、かかる場合には、優先度を図５のフローチャートに従って優先度を決定し、当該優先度から再送エラー回数に応じた数値（例えば、１０）を加算するようにしてもよい。優先度が１００より大きな値になる場合には、優先度を強制的に１００に決定してもよい。
【０１０２】
このようにすれば、スプール領域１７１に再配送の電子メールが蓄積され記憶領域が圧迫されるようなメールサーバ１０の場合、配送遅延の問題よりも記憶領域を確保することができる。
【０１０３】
（２）メールヘッダに記載された優先度に基づく配送処理
本実施形態のメールサーバ１０は、電子メールのヘッダ部に記載された優先度情報に基づいて、電子メールの優先度を決定してもよい。例えば、”Ｓｕｂｊｅｃｔ”ヘッダに、“優先度６０“という文字列がある場合には、優先度を６０に決定し、決定された優先度に基づきスプールディレクトリに優先度ディレクトリを作成し、優先度に従って配送処理を行う。
【０１０４】
（３）特定文字列に基づいて優先度を決定する処理
本実施形態のメールサーバ１０は、受信した電子メールのヘッダ部やボディ部に特定文字列を検索し、検索結果に基づき優先度を決定するようにしてもよい。
【０１０５】
例えば、「緊急」という文字列を特定文字列とした場合について説明すると、受信した電子メール（例えば、電子メールのヘッダ部やボディ部）に「緊急」の文字列が存在する場合には、優先度の初期値（＝５０）に、所定値（＝１０）を加算した値、すなわち６０を、その電子メールの優先度として決定してもよい。一方、受信した電子メールのヘッダ部やボディ部に「緊急」の文字列が存在しない場合には、その電子メールの優先度を初期値（＝５０）に決定する。このようにすれば、緊急の電子メールについては、より優先的に配送することができる。
【０１０６】
また、例えば、スパムメールを連想させる文字列を特定文字列として予め設定し、電子メールにその特定文字列が存在する場合には、優先度の初期値（＝５０）に、所定値（＝４０）を減算した値、すなわち１０を、その電子メールの優先度として決定してもよい。このようにすれば、本来配送すべきでない電子メールの配送を後回しにすることができる。
【０１０７】
また、本実施形態のメールサーバ１０は、メールサイズと特定文字列の検索結果とに基づいて優先度を決定してもよい。例えば、図５のフローチャートに従って優先度を決定し、電子メールに特定文字列が存在する場合に、特定文字列に応じた値を加算（或いは減算）するようにしてもよい。なお、優先度が負の値になる場合には、優先度を強制的に０に決定するようにしてもよい。
【符号の説明】
【０１０８】
１０  メールサーバ、１００  処理部、１１１  受信部、１１２  優先度決定部、
１１３  配送予定時刻決定部、１１４  スプール制御部、１１５  配送部、
１７０  記憶部、１７１  スプール領域
【図１】
0005597466.tif 000002
【図２】
0005597466.tif 000003
【図３】
0005597466.tif 000004
【図４】
0005597466.tif 000005
【図５】
0005597466.tif 000006
【図６】
0005597466.tif 000007
【図７】
0005597466.tif 000008
【図８】
0005597466.tif 000009