JP5482583B2 - メールサーバ装置及び電子メール処理方法 - Google Patents

メールサーバ装置及び電子メール処理方法 Download PDF

Info

Publication number
JP5482583B2
JP5482583B2 JP2010199246A JP2010199246A JP5482583B2 JP 5482583 B2 JP5482583 B2 JP 5482583B2 JP 2010199246 A JP2010199246 A JP 2010199246A JP 2010199246 A JP2010199246 A JP 2010199246A JP 5482583 B2 JP5482583 B2 JP 5482583B2
Authority
JP
Japan
Prior art keywords
mail
emails
user
priority
email
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010199246A
Other languages
English (en)
Other versions
JP2012060257A (ja
Inventor
好昭 内田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2010199246A priority Critical patent/JP5482583B2/ja
Priority to US13/225,659 priority patent/US20120059889A1/en
Publication of JP2012060257A publication Critical patent/JP2012060257A/ja
Application granted granted Critical
Publication of JP5482583B2 publication Critical patent/JP5482583B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/107Computer-aided management of electronic mailing [e-mailing]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/226Delivery according to priorities

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、メールサーバの輻輳を防止する技術に関する。
現在、電子メールは、私的目的のみでなく企業等における業務目的等においても広く利用されている。各ユーザは、パーソナルコンピュータ(以降、PCと表記する)やモバイル端末等のようなユーザ端末にインストールされているメーラーを用いることにより、メールサーバにアクセスし、各ユーザ宛ての電子メールを受信する。
メールサーバには、送信用サーバと受信用サーバとが含まれる。送信用サーバと受信用サーバとは別々のサーバとして実現される場合もある。送信用サーバは、登録されているメールアカウントを有するユーザから送信された電子メールを他のメールサーバに転送する。送信用サーバは、SMTP(Simple Mail Transfer Protocol)サーバ等と呼ばれる
。以降、メールサーバに登録されているメールアカウントを有するユーザを登録ユーザと表記する。受信用サーバは、登録ユーザ宛ての電子メールを受信し、受信された電子メールをそのユーザからの転送要求に応じてユーザ端末に転送する。受信用サーバは、POP(Post Office Protocol)3サーバ、IMAP(Internet Message Access Protocol)サーバ等と呼ばれる。
このようなメールサーバでは、登録ユーザの数及び処理すべき電子メールの数等に応じて、処理負荷が増加する。一方、メールサーバで処理されるべき電子メールは、スパムメール等と呼ばれる不要なものも含めて増加傾向にある。メールサーバの処理負荷がその処理能力を超えてしまうとメールサーバが輻輳状態になり、メールサーバの応答時間が長くなるため、メールサービスや業務に支障が生じる場合がある。
このような問題点を解決するために、高い処理能力を持つメールサーバを利用する方法や、メールサーバの処理負荷を分散させる運用上の工夫等が行われる。
特開平10−164248号公報 特開2004−48492号公報 特開平9−200254号公報 特開平10−79756号公報
しかしながら、上述のような従来の解決手法は、費用の面や企業内の業務の面において、実用的でない。例えば、電子メールに関する問題のみのために、就業規則の変更や部署間の調整は行えない。更に、従来の手法では、メールサーバの処理負荷の一時的急増には対処できない。
企業内メールサーバでは、例えば、出社した社員が一斉にメールチェックを行うため、始業時、特に休暇明けの始業時に、処理負荷が急激に高まる。メールサーバの処理負荷の一時的な急増は、このような例のみにあらず、通常時よりも多くの着信メールが存在する状態で登録ユーザの過半数が集中してメールチェックするような場面において十分に起こり得る。
このようにメールサーバの処理負荷が高まると、メールサーバの応答時間が長くなるため、電子メールに関するサービス品質の低下に繋がる。更に、企業では、従業員が電子メールを確認した後に業務を開始するのが一般的であるため、全体の業務開始が遅れることから、直ちにビジネス損失に繋がってしまう。
本発明の一態様に係る目的は、このような問題点に鑑み、メールサーバの輻輳を防止する技術を提供することにある。
本開示の各態様では、上述した課題を解決するために、それぞれ以下の構成を採用する。
第1の態様は、ユーザ宛ての複数の電子メールを受信する受信手段と、この受信手段で受信された各電子メールの優先度を決定する決定手段と、上記受信手段で受信された複数の電子メールのうちの一部の所定数の電子メールを当該決定手段で決定された優先度に基づいて選択し、上記ユーザの端末装置からの要求受信時において所定数の電子メール以外の電子メールを未着メールとして扱う処理手段と、を備えるメールサーバ装置に関する。
なお、本開示の別態様としては、以上の構成を実現する電子メール処理方法であってもよいし、プログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記憶媒体であってもよい。
上記各態様によれば、メールサーバの輻輳を防止する技術を提供することができる。
本実施形態のメールサーバ装置が適用されるメールシステムの構成例を示す概念図。 実施例1におけるメールサーバ装置の処理構成の例を示す図。 実施例1におけるメール格納部の概念図。 ユーザ指定情報格納部の例を示す図。 実施例1におけるメールサーバ装置の電子メール受信処理を示すフローチャート。 実施例1におけるメールサーバ装置の電子メール受信処理を示すフローチャート。 実施例1におけるメールサーバ装置1のPOPメッセージ応答処理を示すフローチャート。 実施例2におけるメールサーバ装置の処理構成の例を示す図。 実施例2におけるメール格納部の概念図。 実施例2におけるメールサーバ装置のPOPメッセージ応答処理を示すフローチャート。 実施例3におけるメールサーバ装置の処理構成の例を示す図。 実施例3における所定数Nの決定処理を示すフローチャート。
以下、一実施形態としてのメールサーバ装置について具体例を挙げ説明する。以下に挙げた各実施例はそれぞれ例示であり、本実施形態は以下の各実施例の構成に限定されない。
〔システム構成〕
図1は、本実施形態のメールサーバ装置が適用されるメールシステムの構成例を示す概念図である。図1に示されるように、本実施形態のメールサーバ装置1は、ネットワーク3を介して外部メールサーバ装置5、送信者端末6、受信者端末9等と通信可能に接続されている。
送信者端末6及び受信者端末9は、メールサーバ装置1の登録ユーザ、即ち、メールサーバ装置1の内部ドメインのユーザが利用するユーザ端末である。これらユーザ端末は、PC、携帯電話、携帯端末等のような電子メールの送受信機能を有する情報処理装置である。ユーザは、ユーザ端末にインストールされているメーラーを起動することにより、メールサーバ装置1にアクセスし、自身宛ての電子メールの参照、他ユーザ宛ての電子メールの送信等を行う。以降、図1に示されるように、説明の便宜のため、電子メールを送信するユーザ端末としての送信者端末6と電子メールを受信するユーザ端末としての受信者端末9とが区別して説明する。なお、本実施形態は、送信者端末6及び受信者端末9の形態を限定するものではないため、送信者端末6及び受信者端末9は、一般的なメールクライアントであればよい。また、以降、電子メールをEメールとも表記する。
外部メールサーバ装置5は、メールサーバ装置1とは異なるドメイン(以降、外部ドメインと表記する)のメールサーバである。外部メールサーバ装置5は、メールサーバ装置1のドメイン(以降、内部ドメインと表記する)宛てのEメールをSMTP等のプロトコルによりメールサーバ装置1へ転送する。なお、本実施形態は、外部メールサーバ装置5の形態を限定するものではないため、外部メールサーバ装置5は一般的なメールサーバであってもよいし、本実施形態におけるメールサーバ装置1と同様のメールサーバであってもよい。
ネットワーク3は、インターネット等のような公衆網、WAN(Wide Area Network)
、LAN(Local Area Network)、無線通信ネットワーク等である。本実施形態はこのようなネットワーク3の形態を限定しない。ネットワーク3は、POP3、IMAP、SMTP等のようなEメール通信用のプロトコルが実行できるものであればよい。
〔メールサーバ装置のハードウェア構成〕
本実施形態におけるメールサーバ装置1は、情報処理装置としての一般的なハードウェア構成を持つ。即ち、メールサーバ装置1は、ハードウェア構成として、CPU(Central Processing Unit)10のようなマイクロプロセッサ、RAM(Random Access Memory
)11、HDD(Hard Disk Drive)12のようなストレージ、通信制御部15等を有す
る。通信制御部15は、ネットワーク3と接続され、外部メールサーバ装置5、送信者端末6、受信者端末9等とEメールの送受に関するプロトコルを実現する。
メールサーバ装置1では、HDD12等の記憶装置(記録媒体)に格納されたプログラムがCPU10のようなマイクロプロセッサ(コンピュータ)で実行されることにより、上述のようなハードウェアと協働しながら以下に述べるような各処理部を実現する。なお、以下の各実施例では、Eメールに関連する処理部のみを示すが、他の処理部が実現されていてもよい。なお、記録媒体は、USBメモリのような可搬性を有する記録媒体や、CD,DVDのようなドライブ装置を介してデータを読み書き可能なディスク記録媒体を含むことができる。
以下、実施例1におけるメールサーバ装置について説明する。
〔処理構成〕
図2は、実施例1におけるメールサーバ装置の処理構成の例を示す図である。
図2に示されるように、実施例1におけるメールサーバ装置1は、SMTPサーバ20、POPサーバ21、メール格納部27、ユーザ指定情報格納部28等を有する。実施例1では、SMTPサーバ20及びPOPサーバ21は、プロセス、タスク、スレッド等のようなソフトウェア要素として実現される。
メール格納部27は、内部ドメインの各ユーザ宛てのEメールをユーザ毎にそれぞれ格納する。図3は、実施例1におけるメール格納部の概念図である。図3に示されるように、メール格納部27は、内部ドメインの宛先ユーザ(アカウント)毎のメール格納領域30を有する。
各メール格納領域30には、Eメールを格納するメモリ領域として、仮ボックス31、保留ボックス32、メールボックス38がそれぞれ含まれる。仮ボックス31は、送信者端末6や外部メールサーバ装置5から送られてきたEメールを一時的に格納する領域である。メールボックス38は、仮ボックス31に格納されていたEメールが最終的に格納される領域であり、メールボックス38に格納されたEメールは、各ユーザ宛てに届いているEメールとして扱われる。
保留ボックス32は、仮ボックス31に格納されているEメールを新着メールとしてメールボックス38へ移動させる前に、格納する領域である。保留ボックス32は、Eメールの優先度にそれぞれ対応する、第1保留ボックス33、第2保留ボックス34、第3保留ボックス35及び第4保留ボックス36を含む。第1保留ボックス33は第1優先度のEメールを格納し、第2保留ボックス34は第2優先度のEメールを格納し、第3保留ボックス35は第3優先度のEメールを格納し、第4保留ボックス36は第4優先度のEメールを格納する。ここでは、第1優先度が最も高い優先度を示し、第4優先度が最も低い優先度を示すものとする。これにより、仮ボックス31に格納されたEメールは、そのEメールの優先度に応じた保留ボックス32で保留された後、最終的に、新着メールとしてメールボックス38へ移動させられる。
ユーザ指定情報格納部28は、上述のようなEメールの優先度を決めるための各ユーザの指定情報がそれぞれ格納される。図4は、ユーザ指定情報格納部の例を示す図である。ユーザ指定情報格納部28には、各ユーザについて、ユーザアカウント、最優先情報、中優先情報、低優先情報がそれぞれ格納される。ユーザアカウントは、各ユーザを識別するための情報である。
最優先情報、中優先情報、低優先情報には、各ユーザ宛てで受信されるEメールの優先度を決めるための情報として、送信元のEメールアドレス、又はその一部(ユーザ名、ドメイン等)が格納される。実施例1では、送信元のEメールアドレスが同一ドメイン(内部ドメイン)でありかつ最優先情報で指定された範囲に含まれる場合には、そのEメールの優先度は第1優先度に決定される。送信元のEメールアドレスが異なるドメイン(外部ドメイン)でありかつ中優先情報で指定された範囲に含まれる場合には、そのEメールの優先度は第2優先度に決定される。送信元のEメールアドレスが異なるドメイン(外部ドメイン)でありかつ低優先情報で指定された範囲に含まれる場合には、そのEメールの優先度は第4優先度に決定される。
例えば、社内の社員(ユーザ名:COWORKER)から送られてきたEメールは業務内容の可能性が高いため優先的に参照されることが好ましい。この場合、最優先情報フィールドに、そのユーザ名(COWORKER)が設定される。一方、所定ショップのお買い得情報等のように定期的に配信されてくるEメールの緊急度はあまり高くない。よって、この場合、低優
先情報フィールドにその送信元Eメールアドレス(information@shop.co.jp)が格納される。つまり、各ユーザにとって、最も優先的に参照したいEメールの送信元情報が最優先情報フィールドに格納され、後で参照しても構わないEメールの送信元情報が低優先情報フィールドに格納される。
SMTPサーバ20は、送信者端末6から送信された外部ドメイン宛てのEメールを受信し、その外部ドメインに対応する外部メールサーバ装置5へSMTP等のプロトコルを用いてそのEメールを転送する。一方、SMTPサーバ20は、受信処理部23、分類部24等を有し、外部メールサーバ装置5、送信者端末6等から送られる内部ドメイン宛てのEメールをSMTP等のプロトコルを用いて受信する。なお、本実施形態は、この内部ドメイン宛てのEメールの受信プロトコル及び外部ドメイン宛てのEメールの転送プロトコルをSMTPに限定するものではない。
受信処理部23は、内部ドメイン宛てのEメールを受信すると、そのEメールのヘッダ情報に含まれる宛先情報(Toフィールド、Ccフィールド、Bccフィールド)が示すユーザのメール格納領域30の仮ボックス31にそのEメールを格納する。受信処理部23は、Eメールの受信及び仮ボックス31への格納を完了すると、分類部24を起動する。
分類部24は、仮ボックス31に格納されているEメールの優先度を決定し、その優先度に対応する保留ボックス32に仮ボックス31内のEメールを移す。分類部24は、Eメールのヘッダ情報に含まれる送信者情報(Fromフィールド、Senderフィールド)を取得し、この送信者情報に応じてそのEメールの優先度を決定する。
具体的には、分類部24は、送信者情報が内部ドメインのユーザでありかつそのEメールの宛先ユーザに関するユーザ指定情報格納部28の最優先情報の範囲に含まれる場合には、そのEメールの優先度を第1優先度に決定する。分類部24は、送信者情報が内部ドメインのユーザでありかつ第1優先度に含まれないもの、及び、送信者情報が外部ドメインのユーザでありかつそのEメールの宛先ユーザに関するユーザ指定情報格納部28の中優先情報の範囲に含まれる場合には、そのEメールの優先度を第2優先度に決定する。また、分類部24は、送信者情報が外部ドメインのユーザでありかつそのEメールの宛先ユーザに関するユーザ指定情報格納部28の低優先情報の範囲に含まれる場合には、そのEメールの優先度を第4優先度に決定する。分類部24は、その送信者情報が第1優先度、第2優先度及び第4優先度に含まれない場合には、そのEメールの優先度を第3優先度に決定する。
分類部24は、このようにEメールの優先度を決定すると、第1優先度に決定されたEメールを第1保留ボックス33に移し、第2優先度に決定されたEメールを第2保留ボックス34に移し、第3優先度に決定されたEメールを第3保留ボックス35に移し、第4優先度に決定されたEメールを第4保留ボックス36に移す。なお、分類部24は、このような仮ボックス31のEメールの移動処理を定期的に行うようにしてもよい。
POPサーバ21は、受信者端末9からの要求に応じて、その受信者端末9のユーザのメールボックス38に格納されるEメールを対象としてPOP3、IMAP等のプロトコルを用いてその受信者端末9へ応答する。なお、本実施形態は、POPサーバ21と受信者端末9との間のプロトコルを限定するものではない。
POPサーバ21は、要求受信部25、要求処理部26等を有する。
要求受信部25は、受信者端末9からのアクセスを受けると、そのユーザのための所定
数NのEメールを保留ボックス32からメールボックス38へ移す。例えば、要求受信部25は、Eメールの移動処理を開始するにあたり、そのユーザを認証する。具体的には、要求受信部25は、受信者端末9からUSERコマンド及びPASSコマンドを受信し、これらコマンドに含まれるユーザアカウント及びパスワードを登録されている正規データと照合し、照合に成功した場合にEメールの移動処理を開始する。
要求受信部25は、アクセス元のユーザに関する所定数Nを取得する。この所定数Nは、ユーザ毎に予め決められておりメモリ等に格納されていてもよいし、全ユーザ同一の固定値とされてもよい。
要求受信部25は、所定数Nを得ると、メール格納領域30の保留ボックス32に格納されるEメールの存在を確認し、Eメールが格納される、優先度の高い保留ボックスから順に(第1保留ボックス33、第2保留ボックス34、第3保留ボックス35、第4保留ボックス36の順に)N個までEメールを保留ボックス32からメールボックス38へ移す。要求受信部25は、Eメールの移動処理を完了すると、要求処理部26を実行する。
要求処理部26は、ユーザ認証後に受信者端末9から送られる要求に対して、メールボックス38に格納されるEメールを対象として応答する。例えば、POP3では、要求処理部26は、STATコマンドを受信者端末9から受けた場合、そのユーザのメールボックス38に格納されるEメールの数、及び、そのEメールの合計データサイズを含めた応答メッセージを返信する。要求処理部26は、POP3における、メールリストを取得するためのLISTコマンド、指定メールを読み出すためのRETRコマンド、指定メールを削除するためのDELEコマンド等に対して、メールボックス38に格納されるEメールに対して処理する。
要求処理部26は、POP3、IMAP等の標準化された応答メッセージに、メールボックス38内のEメールに関する情報のみでなく、後回しされ保留ボックス32に保留されているEメールに関する情報を付加するようにしてもよい。例えば、STATコマンドの応答として、「+OK (メッセージボックス38内のEメールの数) (メッセージボックス38内のEメールの合計データサイズ)」に加えて、保留ボックス32内のEメールの数が付加される。このように新たな情報は付加情報とすることにより、メーラーが新たな情報に対応していない場合であっても、このような応答メッセージを正常に処理することができる。
〔実施例1における動作例〕
以下、実施例1におけるメールサーバ装置1の動作例について図5A及び5B、並びに図6を用いて説明する。図5A及び5Bは、実施例1におけるメールサーバ装置1の電子メール受信処理を示すフローチャートである。
外部メールサーバ装置5、送信者端末6等から内部ドメイン宛てのEメールが送信されると、メールサーバ装置1では、SMTPサーバ20の受信処理部23が当該Eメールを受信する(S51)。受信処理部23は、受信されたEメールのヘッダ情報に含まれる宛先情報(Toフィールド、Ccフィールド、Bccフィールド等)を参照する(S52)。受信処理部23は、この宛先情報で示されるユーザのメール格納領域30の仮ボックス31にそのEメールを格納する(S53)。
続いて、分類部24は、仮ボックス31に格納されているEメールを選択する(S54)。分類部24は、選択されたEメールのヘッダ情報に含まれる送信元情報(Fromフィールド、Senderフィールド等)を参照する(S55)。分類部24は、宛先としてのユーザに関する、最優先情報、中優先情報及び低優先情報をユーザ指定情報格納部2
8から抽出する(S56)。
分類部24は、送信元情報及びユーザの指定情報に基づいて、その選択されたEメールの優先度を以下のように決定する。分類部24は、送信元情報が内部ドメインに含まれ、かつ、最優先情報に含まれるか否かを判定する(S57)。分類部24は、送信元情報が内部ドメインに含まれ、かつ、最優先情報に含まれると判定すると(S57;YES)、その選択されたEメールの優先度を第1優先度に決定する(S58)。分類部24は、送信元情報が内部ドメインに含まれないか、又は、最優先情報に含まれないと判定すると(S57;NO)、更に、送信元情報が内部ドメインに含まれるか否かを判定する(S59)。分類部24は、送信元情報が内部ドメインに含まれ、かつ、最優先情報に含まれないと判定すると(S59;YES)、その選択されたEメールの優先度を第2優先度に決定する(S60)。
分類部24は、送信元情報が内部ドメインに含まれないと判定すると(S59;NO)、更に、送信元情報が外部ドメインに含まれ、かつ、中優先情報に含まれるか否かを判定する(S61)。分類部24は、送信元情報が外部ドメインに含まれ、かつ、中優先情報に含まれると判定すると(S61;YES)、その選択されたEメールの優先度を第2優先度に決定する(S62)。分類部24は、送信元情報が外部ドメインに含まれ、かつ、中優先情報に含まれないと判定すると(S61;NO)、更に、送信元情報が外部ドメインに含まれ、かつ、低優先情報に含まれるか否かを判定する(S63)。
分類部24は、送信元情報が外部ドメインに含まれ、かつ、低優先情報に含まれると判定すると(S63;YES)、その選択されたEメールの優先度を第4優先度に決定する(S65)。一方で、分類部24は、送信元情報が外部ドメインに含まれ、かつ、低優先情報に含まれないと判定すると(S63;NO)、その選択されたEメールの優先度を第3優先度に決定する(S65)。
分類部24は、選択されたEメールの優先度をこのように決定すると、仮ボックス31から、当該決定された優先度に対応する保留ボックス32にそのEメールを移す(S67)。具体的には、Eメールの優先度が第1優先度に決定された場合には、そのEメールは、第1保留ボックス33に移される。Eメールの優先度が第2優先度に決定された場合には、そのEメールは、第2保留ボックス34に移される。Eメールの優先度が第3優先度に決定された場合には、そのEメールは、第3保留ボックス35に移される。Eメールの優先度が第4優先度に決定された場合には、そのEメールは、第4保留ボックス36に移される。
分類部24は、このような仮ボックス31から保留ボックス32へのEメールの移動処理を仮ボックス31内のEメールがなくなるまで継続する(S68)。また、他のユーザのための仮ボックス31も対象に同様の処理が実行される。
図6は、実施例1におけるメールサーバ装置1のPOPメッセージ応答処理を示すフローチャートである。なお、図6の例では、POP3を利用した場合の動作例が示されるが、IMAP等のような他のプロトコルが利用される場合でも利用するメッセージテキストの内容が相違するのみであり、基本的には同様の動作が実行される。
受信者端末9では、ユーザがメーラーを操作することによりメールチェックを行うと、メールサーバ装置1に対してPOP3が開始される。即ち、受信者端末9は、メールサーバ装置1のPOPサーバ21のポートに対してアクセスする。受信者端末9からPOP3のポートに対してアクセスされると、メールサーバ装置1では、POPサーバ21の要求受信部25がこのアクセスに対して応答する。POP3のコマンドシーケンスの例では、
要求受信部25は、その受信者端末9からUSERコマンドを受信し、この受信に対してパスワードを要求する旨の応答を行うと、PASSコマンドを受信する。要求受信部25は、このように受信者端末9からUSERコマンド及びPASSコマンドを受信する(S71)。
要求受信部25は、USERコマンドに含まれるユーザアカウント及びPASSコマンドに含まれるパスワードを予め登録されている正規データを用いて照合することにより、アクセスしてきているユーザを認証する(S72)。要求受信部25は、アクセスユーザが正規ユーザであることを確認すると、そのユーザの所定数Nを取得する(S73)。
続いて、要求受信部25は、メールカウント(n)を初期化(クリア)する(S74)。要求受信部25は、アクセスユーザに関する保留ボックス32のうち最も優先度の高い第1保留ボックス33を選択する(S75)。要求受信部25は、選択された第1保留ボックス33に格納されている(N−n)個以下のEメールをそのアクセスユーザのメールボックス38へ移す(S76)。この場合、メールカウント(n)はゼロであるため、所定数N個以下のEメールが移される。要求受信部25は、移されたEメール数をメールカウント(n)に加算する(S77)。
要求受信部25は、メールカウント(n)が所定数Nより小さいか否かを確認する(S78)。メールカウント(n)が所定数Nより小さい場合(S78;YES)、要求受信部25は、次に優先度の高い第2保留ボックス34を選択し(S75)、上述と同様のEメール移動処理を行う(S76、S77、S78)。要求受信部25は、第2保留ボックス34からメールボックス38に移されたEメール数をメールカウント(n)に加算し(S77)、再度、メールカウント(n)が所定数Nより小さいか否かを確認する(S78)。このようにして、要求受信部25は、保留ボックス32からメールボックス38へ移されたEメールの数が所定数Nに達するまで、第3保留ボックス35を選択し、更に、第4保留ボックス36を選択する。
要求受信部25は、メールカウント(n)が所定数Nに達するか、又は、全保留ボックス32を選択し終えると(S78;NO)、要求処理部26を実行する。このとき、要求受信部25は、保留ボックス32に残っているEメールが存在する場合には、それらの数の合計を要求処理部26へ渡すようにしてもよい。
要求処理部26は、POP3コマンドシーケンスにおいてユーザ認証以降に送られてくる各コマンドに対して、そのアクセスユーザのメールボックス38内のEメールを対象にして応答する(S79)。即ち、要求処理部26は、メールサーバ装置1では受信されているものの保留ボックス32内に格納されているEメールについては、未着メールとして扱い、STATコマンドの応答に含めるためのメール数やメールサイズ等の対象としない。このような未着メールとして扱われた保留ボックス32内のEメールは、次回、受信者端末9からPOP3のアクセスが開始されたとき、即ち、次回のメールチェック時にメールボックス38に移され、新着メールとして扱われる。
〈実施例1の作用及び効果〉
上述のように、実施例1におけるメールサーバ装置1では、メール転送用プロトコルにより内部ドメイン宛てのEメールが受信された場合には、その送信元情報に基づいてそのEメールの優先度が判定され、その優先度に応じた保留ボックス32に格納される。一方、受信者端末9からメール受信要求が送られてきた場合には、優先度の高い保留ボックスから順に選択され、所定数N以下のEメールが保留ボックス32からメールボックス38に移される。以降、受信者端末9からの要求に対して、そのユーザのメールボックス38内のEメールが着信メールとして扱われる。
このような態様によれば、同じユーザ宛てに送られ、メールサーバ装置1に到達したEメールが複数存在した場合で、そのEメールが所定数Nより多い場合には、当該複数のEメールのうち優先度の低いEメールは未着メールとして扱われる。よって、所定数Nをメールサーバ装置1の処理能力に応じた値に設定しておけば、新着メールが大量に存在する場合であっても、メールサーバ装置1の処理負荷の一時的な急増を抑えることができる。これは、各ユーザが一斉にメールチェックをした場合であっても、各ユーザに関して新着メールとして扱われるEメールの数は所定数Nに制限されるためである。結果、実施例1によれば、メールサーバ装置1の輻輳を防ぐことができる。
以下、実施例2におけるメールサーバ装置について説明する。
〔処理構成〕
図7は、実施例2におけるメールサーバ装置の処理構成の例を示す図である。実施例2におけるメールサーバ装置1は、実施例1における分類部24がメール移動部71に置き換えられる以外は、実施例1と同様の構成を有する。但し、各部の処理は一部実施例1と異なる。以降、実施例1と異なる内容を中心に説明する。
図8は、実施例2におけるメール格納部の概念図である。図8に示されるように、実施例2におけるメール格納部27では、保留ボックス32は各優先度に応じて区分けされていない。各ユーザに対応する各メール格納領域30には、仮ボックス31、保留ボックス32、メールボックス38がそれぞれ含まれる。
SMTPサーバ20のメール移動部71は、受信処理部23による、Eメールの受信及び仮ボックス31への格納が完了すると実行される。メール移動部71は、仮ボックス31内にEメールが存在する各ユーザに関し、仮ボックス31内のEメールを保留ボックス32へ移す。よって、実施例2では、SMTPサーバ20は、Eメールの優先度を判定しない。
実施例2における要求受信部25は、所定数NのEメールを保留ボックス32からメールボックス38へ移す際に、保留ボックス32内のEメールの優先度を判定し、優先度の高いEメールから順に移動対象に決定する。Eメールの優先度の決定手法は、実施例1における分類部24の手法と同様である。即ち、実施例2における要求受信部25は、ユーザ指定情報格納部28のユーザ指定情報を参照する。
実施例2における要求処理部26は、実施例1の処理に加えて、PASSコマンドの応答メッセージに、メールボックス38内のEメールの数及びその合計データサイズを含めるのみでなく、保留ボックス32内に保留されているEメールの数を付加する。例えば、要求処理部26は、「OK (ユーザ名) has (メールボックス38内のEメールの数) messages((メールボックス38内のEメールの合計データサイズ))
(保留ボックス32内のEメールの数) defered.」といったテキストを応答する。
要求処理部26は、保留ボックス32内のEメールの数がユーザ毎に設定された既定値XNより多い場合には、「Note! (保留ボックス32内のEメールの数) defered.」といった注意を促すテキストを付加するようにしてもよい。
〔実施例2における動作例〕
以下、実施例2におけるメールサーバ装置1の動作例について図9を用いて説明する。
図9は、実施例2におけるメールサーバ装置1のPOPメッセージ応答処理を示すフローチャートである。なお、図9の例では、POP3を利用した場合の動作例が示されるが、IMAP等のような他のプロトコルが利用される場合でも利用するメッセージテキストの内容が相違するのみであり、基本的には同様の動作が実行される。
実施例2におけるメールサーバ装置1においても、メールカウント(n)をクリアするまでは(S71、S72、S73、S74)、実施例1と同様の処理が実行される。
要求受信部25は、移動するEメールの優先度を高い順に選択する。まず、要求受信部25は、最も高い第1優先度を選択する(S91)。要求受信部25は、アクセスユーザに関する保留ボックス32内のEメールのうち、第1優先度のEメールの存在を確認する(S92)。要求受信部25は、第1優先度のEメールがあると判定すると(S92;YES)、第1優先度を持つ(N−n)個以下のEメールを保留ボックス32からメールボックス38へ移す(S93)。この場合、メールカウント(n)はゼロであるため、所定数N個以下のEメールが移される。要求受信部25は、移されたEメール数をメールカウント(n)に加算する(S94)。
要求受信部25は、メールカウント(n)が所定数Nより小さいか否かを確認する(S95)。メールカウント(n)が所定数Nより小さい場合(S95;YES)、要求受信部25は、次に優先度の高い第2優先度を選択し(S91)、上述と同様のEメール移動処理を行う(S92、S93、S94)。要求受信部25は、保留ボックス32からメールボックス38に移された、第2優先度のEメールの数をメールカウント(n)に加算し(S94)、再度、メールカウント(n)が所定数Nより小さいか否かを確認する(S95)。このようにして、要求受信部25は、保留ボックス32からメールボックス38へ移されたEメールの数が所定数Nに達するまで、第3優先度を選択し、更に、第4優先度を選択する。
要求受信部25は、メールカウント(n)が所定数Nに達するか、又は、全優先度を選択し終えると(S95;NO)、要求処理部26を実行する。このとき、要求受信部25は、保留ボックス32に残っているEメールが存在する場合には、それらの数の合計を要求処理部26へ渡すようにしてもよい。
要求処理部26は、メールボックス38内のEメールの数及びその合計データサイズ、並びに、保留ボックス32内に保留されているEメールの数を含めたメッセージを、PASSコマンドの応答メッセージとして生成し、受信者端末9へ応答する(S79)。また、要求処理部26は、PASSコマンド以降に送られてくる各コマンドに対して、そのアクセスユーザのメールボックス38内のEメールを対象にして応答する。
なお、上述の動作例における各Eメールの優先度の判定は、Eメールの移動処理と共にEメール1つずつに対して順次行われてもよいし、Eメールの移動処理の前に保留ボックス32内の全Eメールに対して行われるようにしてもよい。
〈実施例2の作用及び効果〉
上述のように、実施例2におけるメールサーバ装置1では、メール転送用プロトコルにより内部ドメイン宛てのEメールが受信された場合には、そのEメールは保留ボックス32に格納される。一方、受信者端末9からメール受信要求が送られてきた場合には、そのアクセスユーザに関する保留ボックス32に格納されるEメールのうち、優先度の高いEメールから順に所定数N以下のEメールが保留ボックス32からメールボックス38に移される。つまり、実施例2では、実施例1と異なり、SMTPサーバ20がEメールの優先度を判定するのではなく、POPサーバ21がEメールの優先度を判定する。
実施例2におけるこのような態様においても、実施例1と同様の効果を得ることができる。
以下、実施例3におけるメールサーバ装置について説明する。
〔処理構成〕
図10は、実施例3におけるメールサーバ装置の処理構成の例を示す図である。実施例3におけるメールサーバ装置1は、実施例1の構成に加えて、更に、負荷測定部81、所定数決定部82を有する。なお、図10では、実施例1の構成をベースとする例が示されたが、メールサーバ装置1は、実施例2の構成に加えて、更に、負荷測定部81、所定数決定部82を有するようにしてもよい。以降、実施例1及び2と異なる内容を中心に説明する。
負荷測定部81は、メールサーバ装置1の処理負荷を測定する。例えば、負荷測定部81は、CPU10の負荷、受信者端末9への応答時間を計測することにより当該処理負荷を測定する。また、負荷測定部81は、保留ボックス32に格納されているEメールの数、アクセスしている受信者端末9の数に応じて処理負荷を推定するようにしてもよいし、上記各情報の組み合わせにより処理負荷を決定するようにしてもよい。本実施形態はメールサーバ装置1の処理負荷の測定手法を限定するものではない。負荷測定部81は、取得された処理負荷の情報を所定数決定部82へ送る。
所定数決定部82は、負荷測定部81から送られる処理負荷の情報に応じて、当該所定数Nを決定する。具体的には、所定数決定部82は、メールサーバ装置1の処理負荷が高負荷である場合には所定数Nを減らし、メールサーバ装置1の処理負荷が軽負荷である場合には所定数Nを増やす。処理負荷が高負荷か軽負荷かの判定は、所定の閾値が利用されてもよい。また、所定数Nの増減量は、その処理負荷に応じて可変されてもよいし、固定量とされてもよい。
また、アクセスユーザ(u)毎に所定数N(u)がそれぞれ設けられている場合には、各ユーザの所定数N(u)に対してそれぞれ上記増減処理が行われれば良い。更に、所定数N(u)が増減されるユーザとそうでないユーザとを区別し、増減されるユーザの所定数N(u)のみが増減処理されるようにしてもよい。
このようにメールサーバ装置1の処理負荷に応じて更新された所定数Nは、要求受信部25により参照される。なお、負荷測定部81及び所定数決定部82の動作タイミングは、連動していてもよいし、連動していなくともよいし、所定の周期であってもよい。
〔実施例3における動作例〕
図11は、実施例3における所定数Nの決定処理を示すフローチャートである。図11では、メールサーバ装置1の処理負荷として、アクセス中の受信者端末9の数及び受信者端末9への平均応答時間が利用される例が示される。
負荷測定部81は、アクセス中の受信者端末9の数及び受信者端末9への平均応答時間を任意のタイミングで取得する(S111)。取得された各情報は、所定数決定部82に送られる。
所定数決定部82は、受信者端末の数が第1閾値よりも多い、又は、平均応答時間が第2閾値よりも大きいことを確認する(S112)。第1閾値及び第2閾値は、予めメモリ
等に格納される。所定数決定部82は、受信者端末の数が第1閾値よりも多い、又は、平均応答時間が第2閾値よりも大きいことを確認すると(S112;YES)、メールサーバ装置1の処理負荷が高いと判定する。所定数決定部82は、メールサーバ装置1の処理負荷が高いと判定すると、所定数Nを減じる(S113)。
一方で、所定数決定部82は、受信者端末の数が第1閾値以下であり、かつ、平均応答時間が第2閾値以下であることを確認すると(S112;NO)、更に、受信者端末の数が第3閾値よりも少ない、かつ、平均応答時間が第4閾値よりも短いことを確認する(S114)。第3閾値及び第4閾値は、予めメモリ等に格納される。所定数決定部82は、受信者端末の数が第3閾値よりも少ない、かつ、平均応答時間が第4閾値よりも短いことを確認すると(S114;YES)、メールサーバ装置1の処理負荷が軽いと判定する。所定数決定部82は、メールサーバ装置1の処理負荷が軽いと判定すると、所定数Nを増やす(S115)。
なお、所定数決定部82は、受信者端末の数が第1閾値以下であり、かつ、平均応答時間が第2閾値以下であり(S112;NO)、更に、受信者端末の数が第3閾値以上であるか又は平均応答時間が第4閾値以上である場合には、通常の処理負荷と判定し、所定数Nの増減を行わない。
〔実施例3の作用及び効果〕
上述のように実施例3におけるメールサーバ装置1では、保留ボックス32からメールボックス38へ移されるEメールの数の上限値となる所定数Nがメールサーバ装置1の処理負荷に応じて更新される。具体的には、メールサーバ装置1の処理負荷が高くなると所定数Nが減らされ、当該処理負荷が低くなると所定数Nが増やされる。
これにより、メールサーバ装置1の処理負荷が高い場合には、処理負荷が通常の場合よりも多くのEメールが未着メールとして扱われ、メールサーバ装置1の処理負荷が低い場合には、処理負荷が通常の場合よりも未着メールとして扱われるEメールの数が少なくなる。
従って、実施例3によれば、メールサーバ装置1の処理負荷の一時的な急増を抑え、輻輳を防ぐことができるだけでなく、メールサーバ装置1の処理負荷に応じた数のEメールが処理されるため、メールサーバ装置1の処理能力を効率よく利用することができる。
[変形例]
SMTPサーバ20及びPOPサーバ21は、上述の各実施例のように1台の装置内で実現されてもよいし、それぞれ別々の装置で実現されるようにしてもよい。
また、上述の各実施例で示されるように、受信されたEメールが仮ボックス31に一度格納されてから保留ボックス32へ移されるのは、Eメールの排他制御のためである。よって、Eメールの排他制御が可能であれば、仮ボックス31に格納されることなく、保留ボックス32へ格納されるようにしてもよい。
[補足]
以下、上述の実施形態の作用及び効果をM/M/1の待ち行列モデルを用いて検証した結果を示す。
受信者端末9の総数をNとし、各受信者端末9が単位時間内にメールチェックする割合をrとする。rは、端末がメールチェックする時間間隔と考えてもよい。つまり、一分間で全体として(N×r)回のメールチェックが発生すると考える。また、待ち時間がない
場合に1つのメールチェックで平均uの処理時間がかかるとする。つまり、uは、ユーザが一人だけの場合のメールチェックの応答時間であり、Eメールがない場合のメールサーバ装置1の応答時間u0と、Eメールの数mに概ね比例する処理時間ul(m)との和で示される(u=u0+ul(m))。
更に、メールサーバ装置1はこのようなメールチェック要求を単位時間あたりX件処理する能力を持つとする。メールサーバ装置1がメールチェック要求だけを処理しているなら、概ね次の関係が成立する(X=1/u)。
M/M/1の待ち行列モデルを用いれば、受信者端末9におけるメールチェックを要求してから応答を受けるまでの平均的な時間(以降、待ち時間と表記する)は、以下の(式1)で表すことができる。
rNu/(X−rN) (式1)
ここで、メールチェックの所要時間(応答時間)u(m)は、メールサーバ装置1が1分あたり2000件のEメールを処理可能でありメールチェック処理毎に必要となるその他の処理(アカウント管理等)に0.5秒かかると仮定すると、以下の(式2)で表される。
u(m)(秒)=0.5+(メール数:m)×60/2000 (式2)
また、上述のように、メールサーバ装置1における単位時間あたりのメールチェック処理の件数Xは、X=1/u(m)で表される。
このような仮定の下、メールサーバ装置1の処理負荷が一時的に急増するような場面を想定する。具体的には、200台の受信者端末9のうち8割の受信者端末9が始業後5分の間にメールチェックした場面が想定される。このような場面におけるメールチェックの待ち時間は、上記(式1)等を用いて推定すると、以下の表1に示すとおりとなる。下記表1におけるメール件数は、メールサーバ装置1で受信されているがユーザに示されていない1ユーザあたりのEメールの数を示す。メールチェック数は、N=160(台)(=200×0.8)及びr=1/5の場合における上述の(N×r)を示す。
Figure 0005482583
同様に、200台の受信者端末9のうち8割の受信者端末9が始業後4分の間にメールチェックした場面におけるメールチェックの待ち時間は、以下の表2に示すとおりとなる。
Figure 0005482583
このように、メールサーバ装置1で受信されているがユーザに送られていないEメールの数が通常時よりも多くなり、過半数の受信者端末9が集中してメールチェックするような状況では、メールサーバ装置1は容易に輻輳状態に陥ることが分かる。メールサーバ装置1がこのような輻輳状態に陥ると、システムリソースの不足や、各受信者端末9が要求を繰り返すことなどから1時間を越えて輻輳状態が回復できない可能性もある。
ところが、メールサーバ装置1で受信されているがユーザに送られていないEメールのうち、優先処理すべきEメールの数は、通常時と大差ないと想定できる。
そこで、本実施形態に係るメールサーバ装置1は、高い優先度のEメールから所定数NのEメールのみを処理対象としその他のEメールを未着メールとして扱う。これにより、u(m)の値が大きく増加することなく、メールサーバ装置1の処理能力Xも大きく低下することはない。よって、上記表1及び表2の場面であっても、処理対象とするEメールの数の上限を示す所定数Nを例えば20件に設定すれば、他のEメールは未着として扱われるため、輻輳状態とはならないことが検証できる。
よって、本実施形態に係るメールサーバ装置1を業務用の社内メールサーバに適用した場合で、上述の場面のように、連休明け等に社員が一斉にメールチェックを開始した場合には、以下のような状況となることが想定される。
連休明け等の始業後4分間、200人の社員のうちの8割が略一斉にメールチェックする。この4分間は、所定数Nによって各ユーザの処理対象となるEメールの数が制限されるため、メールサーバ装置1の処理負荷は輻輳状態にならないまでも或る程度高い状態が続く。その後、各社員がダウンロードされたEメールを読む時間となるため、メールサーバ装置1の処理負荷は徐々に低下してくる。
更に時間が経過すると、Eメールを読み終えた社員の一部から返信が始まる。また、最初に受信したEメールを読み終えた社員が、再度、メールチェックする。ところが、このメールチェックは、始業開始直後のメールチェックに比べると、時間的に散らばると仮定できる。
この再度のメールチェックでは、上述したように、保留ボックス32内で未着メールとして扱われ保留されていたEメールがメールボックス38に移され、各ユーザにダウンロードされる。このようにメールチェック毎に、未着メールが新着メールとして扱われるため、未着メールとして扱われたEメールであっても必ずユーザに届くことになる。
このように本実施形態におけるメールサーバ装置1によれば、装置自体のハードウェア能力を増強することなく、かつ、ユーザに対して運用上の制約を設けることなく、メールサーバ装置1の処理負荷の一時的急増を抑えることができ、メールサーバ装置1の輻輳状態を防止することができる。
1 メールサーバ装置
6 送信者端末
9 受信者端末
10 CPU(Central Processing Unit)
20 SMTPサーバ
21 POPサーバ
27 メール格納部
28 ユーザ指定情報格納部
30 メール格納領域
31 仮ボックス
32 保留ボックス
33 第1保留ボックス
34 第2保留ボックス
35 第3保留ボックス
36 第4保留ボックス
38 メールボックス
23 受信処理部
24 分類部
25 要求受信部
26 要求処理部
71 メール移動部
81 負荷測定部
82 所定数決定部

Claims (8)

  1. ユーザ宛ての複数の電子メールを受信する受信手段と、
    前記受信手段で受信された各電子メールの優先度を決定する決定手段と、
    前記受信手段で受信された複数の電子メールのうちの一部の所定数の電子メールを前記決定手段で決定された優先度に基づいて選択し、前記ユーザの端末装置からの要求受信時において該所定数の電子メール以外の電子メールを未着メールとして扱う処理手段と、
    を備えることを特徴とするメールサーバ装置。
  2. 前記処理手段は、前記未着メールとして扱った電子メールを前記ユーザの端末装置からの要求を再度受信した際には、前記ユーザ宛ての新着メールとして処理する、
    ことを特徴とする請求項1に記載のメールサーバ装置。
  3. 前記受信手段で受信された複数の電子メールを格納する第1格納手段と、
    前記ユーザ宛てに届いている電子メールとして処理される電子メールを格納する第2格納手段と、
    を更に備え、
    前記処理手段は、前記所定数の電子メールを前記第1格納手段から前記第2格納手段に移動させ、前記未着メールとして扱われる電子メールを前記第1格納手段に残し、前記第2格納手段に格納される電子メールに基づいて前記ユーザの端末装置からの要求に対する応答メッセージを送信する、
    ことを特徴とする請求項1又は2に記載のメールサーバ装置。
  4. 前記メールサーバ装置の処理負荷を取得する取得手段と、
    前記取得手段により取得された処理負荷に応じて、前記所定数を変更する変更手段と、
    を更に備えることを特徴とする請求項1から3のいずれか1項に記載のメールサーバ装置。
  5. 前記処理手段は、前記ユーザの端末装置からの要求に対する応答メッセージに、前記未着メールとして扱われる電子メールに関する情報を付加する、
    ことを特徴とする請求項1から4のいずれか1項に記載のメールサーバ装置。
  6. メールサーバ上で実行される電子メール処理方法において、
    ユーザ宛ての複数の電子メールを受信し、
    前記受信された各電子メールの優先度を決定し、
    前記受信された複数の電子メールのうちの一部の所定数の電子メールを前記優先度に基づいて選択し、
    前記ユーザの端末装置からの要求受信時において前記所定数の電子メール以外の電子メールを未着メールとして扱う、
    ことを含む電子メール処理方法。
  7. メールサーバに含まれるコンピュータによって実行される電子メール処理用のプログラムを記録した記録媒体であって、
    ユーザ宛ての複数の電子メールを受信するステップと、
    前記受信された各電子メールの優先度を決定するステップと、
    前記受信された複数の電子メールのうちの一部の所定数の電子メールを前記優先度に基づいて選択するステップと、
    前記ユーザの端末装置からの要求受信時において前記所定数の電子メール以外の電子メールを未着メールとして扱うステップと、
    を含む前記プログラムを記録した記録媒体。
  8. メールサーバに含まれるコンピュータによって実行される電子メール処理用のプログラムであって、
    ユーザ宛ての複数の電子メールを受信するステップと、
    前記受信された各電子メールの優先度を決定するステップと、
    前記受信された複数の電子メールのうちの一部の所定数の電子メールを前記優先度に基づいて選択するステップと、
    前記ユーザの端末装置からの要求受信時において前記所定数の電子メール以外の電子メールを未着メールとして扱うステップと、
    を含むプログラム。
JP2010199246A 2010-09-06 2010-09-06 メールサーバ装置及び電子メール処理方法 Expired - Fee Related JP5482583B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010199246A JP5482583B2 (ja) 2010-09-06 2010-09-06 メールサーバ装置及び電子メール処理方法
US13/225,659 US20120059889A1 (en) 2010-09-06 2011-09-06 Mail server apparatus and electronic mail processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010199246A JP5482583B2 (ja) 2010-09-06 2010-09-06 メールサーバ装置及び電子メール処理方法

Publications (2)

Publication Number Publication Date
JP2012060257A JP2012060257A (ja) 2012-03-22
JP5482583B2 true JP5482583B2 (ja) 2014-05-07

Family

ID=45771457

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010199246A Expired - Fee Related JP5482583B2 (ja) 2010-09-06 2010-09-06 メールサーバ装置及び電子メール処理方法

Country Status (2)

Country Link
US (1) US20120059889A1 (ja)
JP (1) JP5482583B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111526081B (zh) * 2020-03-16 2023-07-28 中国平安人寿保险股份有限公司 邮件转发方法、装置、设备及存储介质
CN114615228A (zh) * 2022-02-21 2022-06-10 深圳市世强元件网络有限公司 电子邮件推送方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6691156B1 (en) * 2000-03-10 2004-02-10 International Business Machines Corporation Method for restricting delivery of unsolicited E-mail
US20030115270A1 (en) * 2001-06-15 2003-06-19 John Funk High performance email relay system technical field
US8645471B2 (en) * 2003-07-21 2014-02-04 Synchronoss Technologies, Inc. Device message management system
GB0426509D0 (en) * 2004-12-03 2005-01-05 Ibm An email transaction system
US20090113016A1 (en) * 2007-10-24 2009-04-30 Subhabrata Sen Managing email servers by prioritizing emails
US8321520B2 (en) * 2010-11-23 2012-11-27 International Business Machines Corporation Intelligent offload of work to handle peak activity in an enterprise email system

Also Published As

Publication number Publication date
JP2012060257A (ja) 2012-03-22
US20120059889A1 (en) 2012-03-08

Similar Documents

Publication Publication Date Title
JP4387205B2 (ja) アンチスパム技術の統合を可能にするフレームワーク
CN108400927B (zh) 一种针对高并发消息的消息推送方法及装置
US9589254B2 (en) Using e-mail message characteristics for prioritization
US20020120748A1 (en) Method and apparatus for selective delivery and forwarding of electronic mail
US8195753B2 (en) Honoring user preferences in email systems
WO2006129962A1 (en) System for blocking spam mail and method of the same
JP2008517381A (ja) 接続回数及びメッセージの数を制限することで不要な電子メールの受信を規制する方法、装置及びコンピュータソフトウェア
JP5482583B2 (ja) メールサーバ装置及び電子メール処理方法
US10554609B2 (en) Host state-sensing for message interruption
JP6247490B2 (ja) 不正メール判定装置、及びプログラム
US8805936B2 (en) Email server cooperative management for automatic routing of emails based on preferences
JP2006251882A (ja) 迷惑メール処理システム、迷惑メール処理方法、プログラム
JP2003167828A (ja) 電子メール装置、電子メール管理方法、電子メールプログラム
US20050216588A1 (en) Blocking specified unread messages to avoid mailbox overflow
KR101483295B1 (ko) 메시지 공유 방법
JP2005251230A (ja) メールサーバ
JP4692558B2 (ja) メールシステム、サーバ装置、メール管理方法、プログラム、及び記録媒体
KR100699780B1 (ko) 메일 발송 상태 확인을 지원하는 전자 메일 서버 및 전자메일 서비스 제공 방법
CN109218162A (zh) 邮件投递方法及装置
JP2009169600A (ja) 優先順位配信システム、優先順位決定装置および優先順位決定方法
JP6720630B2 (ja) 電子メール配送制御装置、電子メール配送制御方法および電子メール配送制御プログラム
JP3606262B2 (ja) 電子メールサーバ及びその制御方法
JP3147841B2 (ja) メールサーバ、メール配信方法およびメール配信方法の制御プログラムを記録した媒体
JP4807251B2 (ja) メールゲートウェイ装置、メールシステムおよびメール受信状況の提示方法
JP2009302823A (ja) 電子メールシステム、電子メール転送方法、プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130702

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131224

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140121

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140203

R150 Certificate of patent or registration of utility model

Ref document number: 5482583

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees