JP2013219480A - プログラム及びメールシステム - Google Patents

Abstract

【課題】同一の送信者が複数の宛先を指定した同じ内容の電子メールを配送する場合に、エンベロープ宛先の異なる複数の同報メールを一元化して処理可能とする。
【解決手段】メールシステムのプログラムは、差出元から送信された電子メールを受け付ける電子メール受信部１１２と、電子メール受信部１１２から受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する識別情報生成部１１４とを有する。所与の電子メールと他の電子メールが同じ識別情報を有する場合には、所与の電子メールのエンベロープ宛先および他の電子メールのエンベロープ宛先を含むエンベロープと、所与の電子メール又は他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行うメール一元化処理部１１５としてコンピュータを機能させる。
【選択図】図１４

Description

本発明は、プログラム及びメールシステムに関する。

従来から、電子メールがコミュニケーションツールとして利用されており、ＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）から電子メールを受け付けて、電子メールを配送（配信、送信、転送）する処理を行なうＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）が存在する。

ここで、ＭＵＡとは、インターネット上の端末において電子メールを送受信するために使用されるクライアントプログラムであり、ＭＴＡとは、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うサーバのことをいう。

図１６（Ａ）（Ｂ）は、電子メールの送信リレーについて説明するための図である。

端末２１０で作成された電子メールＭ１は、ＭＵＡ２２０から、電子メールを配送（配信、送信、転送）する処理を行なうＭＴＡに送信される。

ユーザが複数の宛先アドレスＢ１、Ｂ２、Ａ２を指定して作成した電子メールＭ１は、例えば図１６（Ａ）に示すように、ＭＵＡ２２０で複数のエンベロープ宛先（エンベロープＴｏ）Ｂ１、Ｂ２、Ａ２を有する１つの電子メールＭ２となり、ＭＴＡ１に送信されることが多い。

電子メールのエンベロープ（Ｅｎｖｅｌｏｐｅ）とは、サーバ（ＭＴＡやＭＵＡ）が電子メールを配送する際に使用する電子メールアドレスであり、ＳＭＴＰセッションにおいて、端末（ＭＵＡ）またはサーバ（ＭＴＡ）が他のサーバに対して送信する、エンベロープ宛先（エンベロープＴｏ）と、エンベロープ差出元（エンベロープＦｒｏｍ）を含む。

通常、電子メールは、エンベロープとメッセージデータで構成される。エンベロープは、エンベロープ差出元と、エンベロープ宛先のデータで構成されており、ＭＵＡから電子メールを受け取ったＭＴＡは、エンベロープ宛先に基づいて、電子メールを配送する処理を行っている。

ＭＴＡ１（２３０）がＭＴＡ２（２４０）に電子メールリレーを行う際に、複数のエンベロープ宛先Ｂ１、Ｂ２、Ａ２を有する１つの電子メールＭ２が、エンベロープ宛先Ｂ１、Ｂ２、Ａ２を有する１通の電子メールとして送信されない場合がある。すなわちエンベロープ宛先Ｂ１の電子メールＭ３−１、エンベロープ宛先Ｂ２の電子メールＭ３−２、エンベロープ宛先Ａ２の電子メールＭ３−３になってバラバラに送信される場合がある。

また図１６（Ｂ）に示すように、ＭＵＡ２２０で、エンベロープ宛先Ｂ１の電子メールＭ３−１、エンベロープ宛先Ｂ２の電子メールＭ３−２、エンベロープ宛先Ａ２の電子メールＭ３−３になってバラバラに送信される場合がある。

特開平３−１０４３４５号公報

複数の宛先が指定されている電子メールを配送する際に、エンベロープ宛先の異なる複数の同報メールとして送信されると、例えば添付ファイルの暗号化を行う場合、電子メールＭ３−１と、電子メールＭ３−２と、電子メールＭ３−３とでは添付ファイルの暗号化パスワードが異なってくるので、送信者側の管理が煩雑になる。

また、例えば電子メールのアーカイブを行う場合、電子メールＭ３−１と、電子メールＭ３−２と、電子メールＭ３−３とがそれぞれ個別にアーカイブ（コピー）されるので、管理が煩雑になるとともに、メールサーバの記憶容量を圧迫する原因になる。

また、例えば電子メールの保留解除（承認）や削除を行う場合、電子メールＭ３−１と、電子メールＭ３−２と、電子メールＭ３−３とがそれぞれ個別に保留解除（承認）や削除の指定が必要となるので、送信者側の管理が煩雑になる。

本願発明は、上述した課題に鑑みたものであり、同一の送信者が複数の宛先を指定した同じ内容の電子メールを配送する場合に、エンベロープ宛先の異なる複数の同報メールを一元化して処理可能なプログラムおよびメールシステムを提供することにある。

（１）本適用例は、電子メールを受信して所与の処理を行うメールサーバのためのプログラムであって、差出元から送信された電子メールを受け付ける電子メール受信部と、受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する識別情報生成部と、所与の電子メールと他の電子メールが同じ識別情報を有する場合には、前記所与の電子メールのエンベロープ宛先と前記他の電子メールのエンベロープ宛先を含むエンベロープと、前記所与の電子メール又は前記他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行うメール一元化処理部と、してコンピュータを機能させるプログラムに関する。また本適用例は、上記プログラムが記憶された情報記憶媒体に関する。

また、本適用例は、電子メールを受信して所与の処理を行うメールシステムであって、
差出元から送信された電子メールを受け付ける電子メール受信部と、受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する識別情報生成部と、所与の電子メールと他の電子メールが同じ識別情報を有する場合には、前記所与の電子メールのエンベロープ宛先と前記他の電子メールのエンベロープ宛先を含むエンベロープと、前記所与の電子メール又は前記他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行うメール一元化処理部と、を含むメールシステムに関する。

本適用例によれば、同一の送信者が複数の宛先を指定した同じ内容の電子メールを配送する場合に、エンベロープ宛先の異なる複数の同報メールを一元化して処理可能なプログラムおよびメールシステムを提供することができる。

（２）また、本適用例のプログラム、情報記憶媒体、メールシステムは、前記メール一元化処理部が、所与の電子メール受信時に受信待ち期限を設定し、前記所与の電子メール受信時に設定した前記受信待ち期限内に、前記所与の電子メールと同じ識別情報を有する前記他の電子メールを受信した場合には、前記所与の電子メールと前記他のメールのメール一元化処理を行ってもよい。

（３）また、本適用例のプログラム、情報記憶媒体、メールシステムは、電子メールの添付ファイルの暗号化処理を行い、暗号化ファイルとパスワードを生成する暗号化処理部としてさらにコンピュータを機能させ、前記暗号化処理部は、 所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルの暗号化処理済みのものがある場合には、前記他の電子メールの暗号化処理で生成したパスワードを用いて前記所与の電子メールの添付ファイルの暗号化処理を行ってもよい。

電子メールの添付ファイルの暗号化処理は、各電子メールの受信待ち期限後に行うようにしてもよい。本適用例によれば、メール一元化処理によりすべての同報メールが一元化されず、複数の同報メールが存在している場合でも、同一ハッシュ値を有する同報メールに対して、同じパスワードで暗号化することができる。

（４）また、本適用例のプログラム、情報記憶媒体、メールシステムは、電子メールの添付ファイルのウイルスチェック処理を行うウイルスチェック処理部としてさらにコンピュータを機能させ、前記ウイルスチェック処理部は、 所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルのウイルスチェック済みのものがある場合には、前記所与の電子メールのウイルスチェック処理を省略してもよい。

電子メールのウイルスチェック処理は、各電子メールの受信待ち期限後に行うようにしてもよい。本適用例によれば、メール一元化処理によりすべての同報メールが一元化されず、複数の同報メールが存在している場合でも、同一ハッシュ値を有する複数の同報メールに対するウイルスチェック処理が１回ですむので、サーバの処理負荷を軽減することができる。

（５）また、本適用例のプログラム、情報記憶媒体、メールシステムは、電子メールを保留し、所定の条件にしたがって保留した電子メールの配送または削除を行う保留処理部としてさらにコンピュータを機能させ、前記保留処理部は、 所与電子メールと同じ識別情報を有する他の電子メールに配送処理または削除処理を行ったものがある場合には、前記所与の電子メールに、前記他の電子メールと同じ処理を行ってもよい。

電子メールの保留処理は、各電子メールの受信待ち期限後に行うようにしてもよい。本適用例によれば、メール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する同報メールに対して、同じ処理（保留解除や削除）を行うことができる。

（６）また、本適用例のプログラム、情報記憶媒体、メールシステムは、電子メールのアーカイブ処理を行うアーカイブ処理部としてさらにコンピュータを機能させ、前記アーカイブ処理部は、所与の電子メールと同じ識別情報を有する他の電子メールにアーカイブ処理済みのものがある場合には、前記所与の電子メールのコピーは行わず、前記所与の電子メールのエンベロープ宛先をアーカイブ領域に格納した前記他の電子メールのエンベロープ宛先に追加してもよい。

電子メールのアーカイブ処理は、各電子メールの受信待ち期限後に行うようにしてもよい。

本適用例によれば、メール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する複数の同報メールに対するコピーは１つで済むので、サーバの格納領域に格納されるデータ量を削減し、格納領域を有効に活用することができる。

本実施形態のサーバの機能ブロックの例。 ユーザが作成した電子メールＭ１の構成を示す図。 ＭＵＡが作成する電子メールＭ２の構成を示す図。 エンベロープの異なる同胞メールの例。 図５（Ａ）〜（Ｃ）は、メール一元化処理について説明するための図。 図６（Ａ）〜（Ｃ）は、受信待ちテーブルについて説明するための図。 一元化処理された電子メールの例を示す図。 識別情報生成処理およびメール一元化処理の流れを示すフローチャート。 ルール判定処理の流れを示すフローチャート。 ファイルの暗号化処理の流れを示すフローチャート。 電子メールの保留処理の流れを示すフローチャート。 電子メールのウイルスチェック処理の流れを示すフローチャート。 電子メールのアーカイブ処理の流れを示すフローチャート。 本実施形態のメールシステムを搭載したサーバの動作例を説明するための図。 本実施形態のメールシステムの適用例。 図１６（Ａ）（Ｂ）は、電子メールの送信リレーについて説明するための図。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また、本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．構成
図１は、本実施形態のサーバ（メールシステムの一例）１０の機能ブロック図の一例である。なお、本実施形態のサーバ１０は、図１の各部を全て含む必要はなく、その一部を省略した構成としてもよい。

記憶部１７０は、処理部１００などのワーク領域となるもので、記憶部１７０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）を記憶することができる。

記憶部１７０は、プログラムやデータなどを格納するものであり、その機能は、ＲＡＭ（ＶＲＡＭ）、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）等によりコンピュータにより読み取り可能な情報記憶媒体で実現できる。

本実施形態の記憶部１７０には、受信待ちテーブル１７１、電子メール管理領域１７２、処理履歴格納領域１７３、ルール格納領域１７４、電子メールアーカイブ領域１７５、パスワード格納領域、各種ＤＢ（ＤＢはデータベースの略、以下同様）を含む。

処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。

処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処
理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、電子メール処理部（ＭＴＡ）１１０と、Ｗｅｂ処理部１２０と、データベース処理部１３０とを含む。

電子メール処理部１１０は、ＳＭＴＰを通じてネットワーク上で電子メールの受信と配送を行う。本実施形態の電子メール処理部１１０は、電子メール送信部１１１、電子メール受信部１１２、解析部１１３、識別情報生成部１１４、メール一元化処理部１１５、暗号化処理部１１６、保留処理部１１７、ウイルスチェック処理部１１８、アーカイブ処理部１１９を含む。

電子メール受信部１１２は、端末２０のＭＵＡ２２によって、差出元から送信され、エンベロープ宛先が指定された電子メールを受信する処理を行う。

解析部１１３は、受信した電子メールを解析する処理を行う。例えば、エンベロープ宛先、エンベロープ差出元、メッセージのヘッダ、メッセージのボディの本文部分を解析する処理を行う。例えば、エンベロープ宛先のうちドメインを抽出したり、メッセージのヘッダのうち、Ｔｏ、Ｃｃ、Ｂｃｃ、Ｓｕｂｊｅｃｔを抽出する処理を行う。また、メッセージのボディ部分のうち、本文を抽出する処理を行う。

識別情報生成部１１４は、受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する。識別情報は、電子メールと１対１に対応する情報であればよく、例えばハッシュ値等でもよい。電子メールのエンベロープとは、サーバが電子メールを配送する際に使用する電子メールアドレスであり、ＳＭＴＰセッションにおいて、端末（ＭＵＡ）がサーバに対して送信する、エンベロープ宛先（エンベロープＴｏ）と、エンベロープ差出元（エンベロープＦｒｏｍ）を含む。電子メールのエンベロープ宛先とは、エンベロープで指定されている宛先（エンベロープＴｏ）を意味する。

受信した電子メールについて、当該電子メールの通信経路に依存しないヘッダ情報に基づき識別情報を生成してもよい。また受信した電子メールについて、当該電子メールの通信経路に依存しないヘッダ情報と本文情報に基づき識別情報を生成してもよい。また受信した電子メールについて、少なくともメッセージＩＤを含むメッセージデータを用いて識別情報を生成してもよい。

メール一元化処理部１１５は、所与の電子メールと他の電子メールが同じ識別情報を有する場合には、前記所与の電子メールのエンベロープ宛先と前記他の電子メールのエンベロープ宛先を含むエンベロープと、前記所与の電子メール又は前記他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行う。電子メールのメッセージデータとはヘッダ情報、電子メール本文情報等である。

メール一元化処理は、例えば所与の電子メールのエンベロープ宛先を他の電子メールのエンベロープ宛先に追加して、所与の電子メールと他の電子メールを１つの電子メールにすることでもよい。

メール一元化処理部１１５は、所与の電子メール受信時に受信待ち期限を設定し、前記所与の電子メール受信時に設定した前記受信待ち期限内に、前記所与の電子メールと同じ識別情報を有する前記他の電子メールを受信した場合には、前記所与の電子メールと前記他のメールのメール一元化処理を行ってもよい。

暗号化処理部１１６は、電子メールの添付ファイルの暗号化処理を行い、暗号化ファイルとパスワードを生成する。暗号化処理部１１６は、所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルの暗号化処理済みのものがある場合には、前記他の電子メールの暗号化処理で生成したパスワードを用いて前記所与の電子メールの添付ファイルの暗号化処理を行ってもよい。電子メールの添付ファイルの暗号化処理は、各電子メールの受信待ち期限後に行うようにしてもよい。

ウイルスチェック処理部１１８は、電子メールの添付ファイルのウイルスチェック処理を行う。ウイルスチェック処理部１１８は、所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルのウイルスチェック済みのものがある場合には、前記所与の電子メールのウイルスチェック処理を省略してもよい。電子メールのウイルスチェック処理は、各電子メールの受信待ち期限後に行うようにしてもよい。

保留処理部１１７は、電子メールを保留し、所定の条件にしたがって保留した電子メールの配送または削除を行う。保留処理部１１７は、所与電子メールと同じ識別情報を有する他の電子メールに配送処理または削除処理を行ったものがある場合には、前記所与の電子メールに、前記他の電子メールと同じ処理を行ってもよい。

保留処理部１１７は、所定の条件に基づいて、保留された電子メールを配送又は削除する処理を行ってもよい。例えば、保留処理部１１７は、端末２０から送信された「保留メールを配送する配送指示」を受信した場合に、保留電子メールを配送する処理を行ってもよい。また、保留処理部１１７は、端末２０から送信された「保留メールを削除する削除指示」を受信した場合に、保留メールを削除する処理を行ってもよい。なお、保留処理部１１７は、端末２０から配送・削除の指示を受信せずに、一定期間経過した場合には、自動的に保留メールを配送する処理、または、自動的に保留メールを削除する処理を行ってもよい。

電子メールの保留処理は、各電子メールの受信待ち期限後に行うようにしてもよい。

アーカイブ処理部１１９は、電子メールのアーカイブ処理を行う。アーカイブ処理部１１９は、所与の電子メールと同じ識別情報を有する他の電子メールにアーカイブ処理済みのものがある場合には、前記所与の電子メールのコピーは行わず、前記所与の電子メールのエンベロープ宛先をアーカイブ領域に格納した前記他の電子メールのエンベロープ宛先に追加してもよい。電子メールの添付ファイルのアーカイブ処理は、各電子メールの受信待ち期限後に行うようにしてもよい。

Ｗｅｂ処理部１２０は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じて、端末２０にインストールされているＷｅｂブラウザ２１などのクライアントソフトウエアの要求に応じてＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ
Ｌａｎｇｕａｇｅ）文書や画像などのデータを送信（提供）する処理、端末のＷｅｂブラウザにおいて受け付けたデータを受信する処理を行う。

管理者用ＵＩ部１２１（ＵＩはユーザインタフェースの略。以下同様。）は、端末２０のＷｅｂブラウザ２１からのアクセス要求に応じて、管理設定用のデータ等を端末２０に送信する処理を行い、端末２０から送信された各ルール（各ルール識別情報）に対応づけてルールの設定情報、各ルールスコアを受信する処理を行う。

ユーザ用ＵＩ部１２２は、端末２０のＷｅｂブラウザ２１からの要求に応じて、ログインしたユーザに応じた保留電子メールのＷｅｂページ（ユーザの電子メールアドレスが差出元となっている保留電子メールのＷｅｂページ）を送信（提供）する処理を行う。またユーザ用ＵＩ部１２２は、端末２０のＷｅｂブラウザ２１からの要求に応じて保留電子メールの送信・削除の指示を受け付けるためのＷｅｂページを送信する処理を行う。ユーザ用ＵＩ部１２２は、端末２０から送信された、保留された電子メールの配送指示、削除指示を受信する処理を行う。

データベース処理部１３０は、データベースに格納されているデータを、登録、更新、削除する処理を行う。例えば、データベース処理部１３０は、管理者用ＵＩ部１２１、ユーザ用ＵＩ部１２２において、端末から受信したデータに基づいて、データベースを更新する処理を行う。

なお、電子メール処理部１１０、Ｗｅｂ処理部１２０、データベース処理部１３０は１つの装置で実行させてもよいし、処理の用途に応じて異なる装置に分散して各処理を実行させるようにしてもよい。

２．電子メールの構成
図１６（Ａ）に示すように、ユーザ端末上で作成した電子メールＭ１に基づき、ＭＵＡが電子メールＭ２を作成して、ＭＴＡに送信される。ここで、ＭＵＡとは、インターネット上の端末において電子メールを送受信するために使用されるクライアントプログラムである。

図２、図３は、ユーザが作成した電子メールＭ１とそれに基づきＭＵＡが作成する電子メールＭ２の構成について説明するための図である。

図２の３００は、差出元アドレス「Ａ１」のユーザが、宛先アドレス「Ｂ１」、「Ｂ２」、ＢＣＣアドレス「Ａ２」に、件名「Ｃ１」、本文「Hello!」、添付ファイルＤの電子メールＭ１を送る場合に、ユーザが作成する電子メールＭ１の構成例を示している。

Ｆｒｏｍ（差出元アドレス）３２１、Ｔｏ（宛先アドレス）３２２、ＢＣＣ（Blind Carbon Copyアドレス）３２５、Ｓｕｂｊｅｃｔ（件名）３２３、本文３３２、添付ファイル３３４については、ユーザが作成する。ＢＣＣは、この覧に記入したアドレスに同じ内容の電子メールが送信されるという電子メールの機能の一つである。本来の受信者であるＴｏ（宛先アドレス）３２２は、同内容の電子メールがＢＣＣに転送されたことはわからない。

ＭＵＡはユーザが作成した電子メールＭ１をそのままＭＴＡにおくるのではなく、電子メールＭ１に基づき作成した電子メールＭ２を送信する。ＭＴＡとは、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うサーバのことをいう。

図３の３００は、ＭＵＡが作成する電子メールＭ２の構成例を示している。図２の電子メールＭ１と同じ項目には同じ番号を付している。通常、電子メールは、エンベロープ（Ｅｎｖｅｌｏｐｅ）３１０とメッセージデータ（ヘッダ３２０と本文等（添付ファイル）３３０）で構成される。エンベロープ３１０は、エンベロープ差出元３１２と、エンベロープ宛先３１４のデータで構成されており、ＭＵＡから電子メールを受け取ったＭＴＡは、エンベロープ宛先に基づいて、電子メールを配送する処理を行っている。

エンベロープ差出元３１２は、図２のＦｒｏｍ（差出元アドレス）３２１に基づき作成され、「Ａ１」になっている。エンベロープ宛先３１４は、図２のＴｏ（宛先アドレス）３２２と図２のＢＣＣ（Blind Carbon Copyアドレス）３２５に基づき作成され、「Ｂ１」、「Ｂ２」、「Ａ２」となっている。

電子メールＭ２のメッセージデータ（ヘッダ３２０と本文等（添付ファイル）３３０）は図２の電子メールＭ１の各項目に基づき生成されるが、電子メールＭ２では、図２のＢＣＣ（Blind Carbon Copyアドレス）３２５はエンベロープ宛先３１４としてのみ使用され、メッセージデータ（ヘッダ３２０）には含まれない。

また、ヘッダ３２０として、ＭＵＡはＤａｔｅ（電子メール作成時刻）３２４、メッセージＩＤ３３５を付加する。メッセージＩＤ３３５は、ＭＵＡがユーザの入力情報に基づき電子メールを作成する際に電子メールに一意に付与する情報であり、メッセージデータを構成するヘッダ情報となる。

図４（Ａ）〜（Ｃ）は、エンベロープの異なる同胞メールの例を示す図である。

複数の宛先を有する電子メールＭ１が、図１６に示すように、エンベロープ宛先Ｂ１を有する電子メールＭ３−１、エンベロープ宛先Ｂ２を有する電子メールＭ３−２、エンベロープ宛先Ａ２を有する電子メールＭ３−３のように、エンベロープ宛先の異なる複数の電子メールになる例について説明する。

図４（Ａ）の３００’−１は、エンベロープ宛先「Ｂ１」の電子メールＭ３−１の構成例を示している。図２の電子メールＭ１、図３の電子メールＭ２と対応する項目には対応する番号を付している。３１０’−１はエンベロープであり、３２０’−１はヘッダ、３３０’−１は本文である（なお、ヘッダと本文をメッセージデータという）。

電子メールＭ３−１のヘッダ３２０’−１と本文３３０’−１の各項目の内容は、図３の電子メールＭ２と同様であるが、エンベロープ宛先が３１４’−１が「Ｂ１」のみになっている。

図４（Ｂ）の３００’−２は、エンベロープ宛先「Ｂ２」の電子メールＭ３−２の構成例を示している。図４（Ａ）の電子メールＭ３−１と対応する項目には対応する番号を付している。電子メールＭ３−２のヘッダ３２０’−２と本文３３０’−２の各項目の内容は、図３の電子メールＭ２、図４（Ａ）の電子メールＭ３−１と同様であるが、エンベロープ宛先が３１４’−２が「Ｂ２」のみになっている。

図４（Ｃ）の３００’−３は、エンベロープ宛先「Ａ１」の電子メールＭ３−３の構成例を示している。図４（Ａ）（Ｂ）の電子メールＭ３−１、Ｍ３−２と対応する項目には対応する番号を付している。電子メールＭ３−３のヘッダ３２０’−３と本文３３０’−３の各項目の内容は、図３の電子メールＭ２、図４（Ａ）（Ｂ）の電子メールＭ３−１、Ｍ３−２と同様であるが、エンベロープ宛先３１４’−３が「Ａ２」のみになっている。

３．メールサーバの動作例
図１４は、本実施形態のメールシステムを搭載したサーバの動作例を説明するための図である。図１と同様の構成については同様の符号を付している。

本実施形態のサーバは、配送処理に用いるエンベロープ宛先及びエンベロープ差出元、メッセージとからなる電子メールを受け付け、当該電子メールを配送するＭＴＡ機能を有する。

ＭＴＡが、電子メールを配送するとは、ＳＭＴＰを通じて、受け付けた電子メールを他のＭＴＡに配送する処理や、メールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送するためのローカル配信エージェントＭＤＡ（Ｍａｉｌ Ｄｅｌｉｖｅｒｙ Ａｇｅｎｔ）に配送する処理、ＭＤＡを介せずにメールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送する場合も含む。

以下、図４（Ａ）〜（Ｃ）の電子メールＭ３−１からＭ３−３のように同一送信者が複数の宛先を指定して送信した同じ内容の電子メールを同報メールとよぶ。

４．識別情報生成処理
本実施形態では、受信した電子メールのハッシュ値を生成してハッシュ値を用いて同報メールの判定を行う。識別情報生成部１１４は、電子メール受信部１１２が受信した電子メールのハッシュ値（識別情報の一例）を生成する。識別情報生成部１１４は、受信した電子メールの通信経路に依存しないメッセージデータ（ヘッダ情報、電子メール本文情報のいずれかのデータ）を用いてハッシュ値を生成してもよい。

ハッシュ値は、ハッシュ関数（チェックサム、チェックディジット、フィンガープリント等）に基づき求められる値である。例えば、ハッシュ関数の入力キーを電子メールの通信経路に依存しないメッセージデータ（ヘッダ情報、電子メール本文情報）の少なくとも１つのデータとし、ハッシュ関数の出力値をハッシュ値とする。このハッシュ値は、同報メールでは同一の値となるので、同報メールを識別（特定）するための情報となる。

例えば、図４（Ａ）の電子メールのＤａｔｅ３２４’−１、ヘッダ宛先３２２’−１、ヘッダ差出元３２１’−１、メッセージＩＤ３３５’−１は電子メールの通信経路に依存しないヘッダ情報であるので、これらをハッシュ関数の入力キーとしてハッシュ値をもとめてもよい。またこれらと図４（Ａ）の電子メールの本文３３２’−１をハッシュ関数の入力キーとしてハッシュ値をもとめてもよい。また添付ファイル３３４’−１も含めてハッシュ関数の入力キーとしてハッシュ値をもとめてもよい。

電子メールＭ３−１からＭ３−３はＤａｔｅ、ヘッダ宛先、ヘッダ差出元、メッセージＩＤ、本文、添付ファイルがいずれも同一なので、生成されるハッシュ値も同一となる。

５．メール一元化処理
メール一元化処理部１１５は、受信した電子メールと同じハッシュ値の他の電子メール（同報メール）が受信待ちテーブル１７１にない場合には、受信した電子メールとそのハッシュ値を受信待ちテーブル１７１に格納する。

受信した電子メールと同じハッシュ値の他の電子メール（同報メール）が受信待ちテーブル１７１にある場合には、受信した電子メールは、受信待ちテーブル１７１の同じハッシュ値を有する他の電子メールとのメール一元化処理を行う。

受信待ちテーブル１７１に同一ハッシュ値がない場合には、当該電子メール受信時に受信待ち終了時刻を設定して、生成したハッシュ値とともに受信待ちテーブル１７１に格納し、受信待ち終了時刻まで保持してもよい。

受信待ちテーブルの電子メールは受信待ち終了時刻を過ぎると、受信待ちテーブルから削除され、メール管理領域１７２に格納される。したがって、電子メールが受信待ちテーブルにある間に、当該電子メールと同じハッシュ値を有する他の電子メールを新たに受信すると、受信待ちテーブルの電子メールと、他の電子メールは一元化され、１つのメールとなる。また電子メールが受信待ちテーブルから削除された後に、当該電子メールと同じハッシュ値を有する他の電子メールを新たに受信すると、当該電子メールと、新たに受信した他の電子メールはこの段階では一元化されず、それぞれエンベロープ宛先の異なる電子メールとして、メール管理領域１７２に格納されることになる。

図５（Ａ）〜（Ｃ）は、メール一元化処理について説明するための図である。

電子メールＭ３−１はエンベロープ宛先が「Ｂ１」、電子メールＭ３−２はエンベロープ宛先が「Ｂ２」、電子メールＭ３−３はエンベロープ宛先が「Ａ１」の電子メールである。これらは同じ内容のメッセージデータ（ヘッダと本文）を有するメール（同報メール）である。電子メールＭ３−１、Ｍ３−２、Ｍ３−３は、異なる通信経路を介して到着する場合もあるため、図５（Ａ）〜（Ｃ）のように受信時刻にタイムラグが生じる場合がある。

例えば図５（Ａ）に示すように、電子メールＭ３−１を時刻ｔ１に受け取り、電子メールＭ３−２を時刻ｔ２に受け取り、電子メールＭ３−３を時刻ｔ３に受け取り、電子メールＭ３−１受信時に設定された受信待ち受け期限の終了する受信待ち終了時刻（Ｔ１）が時刻ｔ４であるとする。

この様な場合、受信待ち終了時刻（Ｔ１）である時刻ｔ４までに受信した電子メールＭ３−１、Ｍ３−２、Ｍ３−３は、同じハッシュ値を有するので一元化されて、エンベロープ宛先「Ｂ１」「Ｂ２」「Ａ２」の１つの電子メールＭ２となる。そして時刻ｔ４が過ぎると電子メールＭ２は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４１０参照）。

また例えば図５（Ｂ）に示すように、電子メールＭ３−１を時刻ｔ１に受け取り、電子メールＭ３−２を時刻ｔ２に受け取り、電子メールＭ３−３を時刻ｔ４に受け取り、電子メールＭ３−１受信時に設定された受信待ち期限の終了する受信待ち終了時刻（Ｔ１）が時刻ｔ３、電子メールＭ３−３受信時に設定された受信待ち期限の終了する受信待ち終了時刻（Ｔ３）が時刻ｔ５であるとする。

この様な場合、受信待ち終了時刻（Ｔ１）である時刻ｔ３までに受信した電子メールＭ３−１、Ｍ３−２は、同じハッシュ値を有するので一元化されて、エンベロープ宛先「Ｂ１」「Ｂ２」の１つの電子メールＭ３−１＋Ｍ３−２となる。そして時刻ｔ３が過ぎると電子メールＭ３−１＋Ｍ３−２は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４２０参照）。

また電子メールＭ３−３を受信した時刻ｔ４には、受信待ちテーブル１７１に同じハッシュ値を有する電子メールは存在しないので、電子メールＭ３−３受信時に受信待ち期限が設定され、受信待ち終了時刻（Ｔ３）である時刻ｔ５まで受信待ちテーブル１７１に保持される。そして時刻ｔ５が過ぎると電子メールＭ３−３は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４３０参照）。

また例えば図５（Ｃ）に示すように、電子メールＭ３−１を時刻ｔ１に受け取り、電子メールＭ３−２を時刻ｔ３に受け取り、電子メールＭ３−３を時刻ｔ５に受け取り、電子メールＭ３−１受信時に設定された受信待ち期限の終了する受信待ち終了時刻（Ｔ１）がｔ２、電子メールＭ３−２受信時に設定された受信待ち期限の終了する受信待ち終了時刻（Ｔ２）がｔ４、電子メールＭ３−３受信時に設定された受信待ち期限の終了する受信待ち終了時刻（Ｔ３）がｔ６であるとする。

電子メールＭ３−１を受信した時刻ｔ１には、受信待ちテーブル１７１に電子メールＭ３−１と同じハッシュ値を有する電子メールは存在しないので、電子メールＭ３−１受信時に受信待ち期限が設定され、受信待ち終了時刻（Ｔ１）である時刻ｔ２まで受信待ちテーブル１７１に保持される。そして時刻ｔ２が過ぎると電子メールＭ３−１は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４４０参照）。

また電子メールＭ３−２を受信した時刻ｔ３には、受信待ちテーブル１７１に電子メールＭ３−２と同じハッシュ値を有する電子メールは存在しないので、電子メールＭ３−２受信時に受信待ち期限が設定され、受信待ち終了時刻（Ｔ２）である時刻ｔ４まで受信待ちテーブル１７１に保持される。そして時刻ｔ４が過ぎると電子メールＭ３−２は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４５０参照）。

また電子メールＭ３−３を受信した時刻ｔ５には、受信待ちテーブル１７１に電子メールＭ３−３と同じハッシュ値を有する電子メールは存在しないので、電子メールＭ３−３受信時に受信待ち期限が設定され、受信待ち終了時刻（Ｔ３）である時刻ｔ６まで受信待ちテーブル１７１に保持される。そして時刻ｔ６が過ぎると電子メールＭ３−３は、受信待ちテーブル１７１から削除され、メール管理領域１７２に格納される（４６０参照）。

図６（Ａ）〜（Ｃ）は、受信待ちテーブルについて説明するための図である。

受信待ちテーブル４００には、電子メール４３０と、当該電子メールのハッシュ値４１０と、当該電子メールのハッシュ値と同じハッシュ値の他の電子メールの受信待ちを終了する受信待ち終了時刻４２０が保持される。受信待ち終了時刻は、当該電子メール受信時の時刻と、受信待ち時間に基づき設定してもよい。受信待ち期限は、例えば受信してからｘ秒間のように相対期限として与えられても良い。

図６（Ａ）の４００を、例えば図５（Ａ）の時刻ｔ１における受信待ちテーブル１７１の状態とし、時刻ｔ１に受信した電子メールＭ３−１のハッシュ値を「５４６７０９９」であるとする（図６（Ａ）の４７４参照）。このような場合、受信待ちテーブルに電子メールＭ３−１と同じハッシュ値はないので、電子メールＭ３−１に受信待ち終了時刻ｈ３が設定され、受信待ちテーブル１７１に格納される。受信待ち期限が受信してからｘ秒間であるとすると、受信待ち終了時刻ｈ３＝ｔ１＋ｘで与えられる。図６（Ｂ）の４７２は、電子メールＭ３−１が受信待ちテーブルに保持されている様子を示している。

図６（Ｂ）の４００を、例えば図５（Ａ）の時刻ｔ２における受信待ちテーブル１７１の状態とし、時刻ｔ２に受信した電子メールＭ３−２のハッシュ値を「５４６７０９９」であるとする（図６（Ｂ）の４７６参照）。このような場合、受信待ちテーブルに電子メールＭ３−２と同じハッシュ値の電子メールＭ３−１があるので（図６（Ｂ）の４７２参照）、電子メールＭ３−２は、受信待ちテーブルには格納されず、すでに受信待ちテーブルに格納されている同じハッシュ値の電子メールＭ３−１のエンベロープ宛先「Ｂ１」に、電子メールＭ３−２のエンベロープ宛先「Ｂ２」が追加されて、エンベロープ宛先が「Ｂ１」「Ｂ２」の電子メールＭ３−１＋Ｍ３−２となる（図６（Ｃ）の４７０参照）。なお、電子メールＭ３−１＋Ｍ３−２のメッセージデータ（ヘッダと本文）は、電子メールＭ３−１および電子メールＭ３−２と同じである。

図７は、一元化処理された電子メールの例を示す図である。３００’−４は、電子メールＭ３−１とＭ３−２が一元化された電子メールＭ３−１＋Ｍ３−２の構成例を示している。図４（Ａ）の電子メールＭ３−１と対応する項目には対応する番号を付している。３１０’−４はエンベロープであり、３２０’−４と３３０’−４はメッセージデータ（ヘッダ３２０’−４、本文３３０’−４）である。電子メールＭ３−１＋Ｍ３−２のヘッダ３２０’−４と本文３３０’−４の各項目の内容は、図４（Ａ）の電子メールＭ３−１および電子メールＭ３−２と同様である。

また、電子メールＭ３−１＋Ｍ３−２のエンベロープ宛先３１４’−４は、電子メールＭ３−１のエンベロープ宛先「Ｂ１」に電子メールＭ３−２のエンベロープ宛先「Ｂ２」を追加した「Ｂ１」「Ｂ２」となっている。

図８は、識別情報生成処理およびメール一元化処理の流れを示すフローチャートである。

電子メール受信待ちの状態において（Ｓ１）、電子メールを受信すると（Ｓ２でＹＥＳ）、受信した電子メールから「Ｄａｔｅ」、「ｆｒｏｍ」、「Ｔｏ」、「Ｍｅｓｓａｇｅ−ＩＤ」のメールヘッダ（Ｈ）を抽出する（Ｓ３）。また受信した電子メールの本文（Ｂ）を抽出する（Ｓ４）。そしてメールヘッダ（Ｈ）と本文（Ｂ）からハッシュ値ｈａｓｈ（Ｈ＋Ｂ）を生成する（Ｓ５）。そして受信待ちテーブルに同一ハッシュ値が存在するか否か判断し（Ｓ６）、存在する場合には（Ｓ６でＹＥＳ）、受信した電子メールの「ＲＥＣＰＴ ＴＯ（エンベロープ宛先）」を、受信待ちテーブルの同一ハッシュ値の電子メールのエンベロープ宛先に追加する（Ｓ７）。そして受信待ちテーブルの同一ハッシュ値の電子メールの受信待ち終了時刻（Ｔ）を更新してもよい（Ｓ８）。この処理は任意であるので、更新しなくてもよい。受信待ちテーブルに同一ハッシュ値が存在しない場合には（Ｓ６でＮＯ）、受信した電子メール、受信待ち終了時刻（Ｔ）、ハッシュ値を受信待ちテーブルに格納する（Ｓ９）。

図１４に戻り、メール管理領域１７２に格納された電子メールの処理について説明する。先に説明したように、受信待ちテーブル１７１に保持されている電子メールは受信終了時刻を過ぎるとメール管理領域１７２に格納される。

６．ルール判定処理
ルール判定処理部１４２は、ルール格納領域に格納されたルール情報に基づき、電子メールに設定されているルール（電子メールに行う処理の種類）を判定する。電子メールに行う処理の種類は、例えば暗号化処理やアーカイブ処理やウイルスチェック処理や保留処理等でもよい。Ｗｅｂブラウザ等で提供された電子メール設定手段１８０によりユーザが電子メールにルールを設定できるようにしてもよい。

図９は、ルール判定処理の流れを示すフローチャートである。

受信待ちテーブルの読み込みを行い（Ｓ１１）、受信待ち終了時刻（Ｔ）＜現在時刻の電子メールがあれば（Ｓ１２でＹＥＳ）、当該電子メール及びハッシュ値をメール格納領域に格納し（Ｓ１３）、受信待ちテーブルから削除して（Ｓ１４）、当該電子メールに設定されているルールを判定する（Ｓ１５）。そして判定したルールに対応する処理を実行する（Ｓ１６）。

７．添付ファイルの暗号化処理
メール管理領域に格納されている所与の電子メールに、添付ファイルの暗号化処理を行うというルールが設定されている場合には、暗号化処理部１１６は、所与の電子メールに暗号化処理を行いパスワードをパスワード格納領域１７６に格納する。

図１０は、ファイルの暗号化処理の流れを示すフローチャートである。

処理対象電子メールに添付ファイルがある場合（Ｓ２１でＹＥＳ）には以下の処理を行う。

パスワード格納領域に同一ハッシュ値のパスワードがある場合（Ｓ２２でＹＥＳ）には、パスワード格納領域からパスワードを取得し（Ｓ２５）、取得したパスワードを用いて、処理対象電子メールの添付ファイルをパスワード付暗号化ファイルに変換して再添付する（Ｓ２６）。

パスワード格納領域に同一ハッシュ値のパスワードがない場合（Ｓ２２でＮＯ）には、パスワードを生成し（Ｓ２３）、生成したパスワードとハッシュ値をパスワード格納領域に格納する（Ｓ２４）。そして生成したパスワードを用いて処理対象電子メールの添付ファイルをパスワード付暗号化ファイルに変換して再添付する（Ｓ２６）。

本実施形態によれば、図５（Ｂ）（Ｃ）のようにメール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する同報メールに対して、同じパスワードで暗号化することができる。

８．保留処理
メール管理領域に格納されている所与の電子メールに、保留処理を行うというルールが設定されている場合には、保留処理部１１７は、所与の電子メールに保留処理を行う。

図１１は、電子メールの保留処理の流れを示すフローチャートである。

保留処理部１１７は、所定期間電子メールを保留する保留処理を行い、ユーザ端末等から所与の保留メールに保留解除指示（承認指示も含む、承認された電子メールは保留解除となる）１９４や削除指示１９６を受け付けると、所与の保留メールの保留解除処理や削除処理を行う。

処理履歴格納領域に所与の保留メールと同一ハッシュ値の処理履歴がある場合には（Ｓ３１でYＥＳ）、同一ハッシュ値の他の保留メールと同じ処理を実行する（Ｓ３２）。例えば同一ハッシュ値の他の保留メールに保留解除処理履歴がある場合には所与の保留メールに保留解除処理を行い、同一ハッシュ値の他の保留メールに削除履歴がある場合には所与の保留メールに削除処理を行う。処理履歴格納領域に所与の保留メールと同一ハッシュ値の処理履歴がない場合には（Ｓ３１でＮＯ）、所与の保留メールに指示された処理を実行し（Ｓ３３）、実行した処理の履歴を所与の保留メールのハッシュ値とともに処理履歴格納領域に格納する（Ｓ３４）。

本実施形態によれば、図５（Ｂ）（Ｃ）のようにメール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する同報メールに対して、同じ処理（保留解除や削除）を行うことができる。

９．ウイルスチェック処理
メール管理領域に格納されている所与の電子メールに、ウイルスチェック処理を行うというルールが設定されている場合には、ウイルスチェック処理部１１８は、所与の電子メールにウイルスチェック処理を行う。

図１２は、電子メールのウイルスチェック処理の流れを示すフローチャートである。

処理履歴格納領域に同一ハッシュ値のウイルスチェック処理履歴がない場合には（Ｓ４１でＮＯ）、ウイルスチェック処理を実行し（Ｓ４２）、ウイルスチェック処理の実行履歴をハッシュ値とともに処理履歴格納領域に格納する（Ｓ４３）。

本実施形態によれば、図５（Ｂ）（Ｃ）のようにメール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する複数の同報メールに対するウイルスチェック処理が１回ですむので、サーバの処理負荷を軽減することができる。

１０．アーカイブ処理
メール管理領域に格納されている所与の電子メールに、アーカイブ処理を行うというルールが設定されている場合には、アーカイブ処理部１１９は、所与の電子メールにアーカイブ処理を行いメールアーカイブ領域１７５に格納する。

図１３は、電子メールのアーカイブ処理の流れを示すフローチャートである。

処理履歴格納領域に所与の電子メールと同一ハッシュ値のアーカイブ処理履歴がある場合には（Ｓ５１でＹＥＳ）、メールアーカイブ領域に格納した電子メールのエンベロープに当該電子メールの「ＲＥＣＰＴ ＴＯ（エンベロープ宛先）」を追加する（Ｓ５２）。

処理履歴格納領域に同一ハッシュ値のアーカイブ処理履歴がない場合には（Ｓ５１でＮＯ）、当該電子メールのコピーをメールアーカイブ領域に格納し（Ｓ５３）、実行したアーカイブ処理の履歴をハッシュ値とともに処理履歴格納領域に格納する（Ｓ５４）。

本実施形態によれば、図５（Ｂ）（Ｃ）のようにメール一元化処理によりすべての同報メールが一元化されず、複数の同報メールがメール管理領域に存在している場合でも、同一ハッシュ値を有する複数の同報メールに対するコピーは１つですむので、サーバの格納領域に格納されるデータ量を削減し、格納領域を有効に活用することができる。

１１．メールシステムの適用例
図１５は、本実施形態のメールシステムの適用例について説明するための図である。

本実施形態のメールシステムは、送信用メールサーバ７００に実装してもよい。この様にすると、ユーザが送信した同報メールは、送信用メールサーバにおいて、一元化され、ウイルスチェック１８６や添付ファイルのＺＩＰ暗号化１８４や電子メールアーカイブ１８２や、保留電子メールの保留解除や削除１８８を一元化して管理することができる。

また本実施形態のメールシステムは、受信用メールサーバ８００に実装してもよい。この様にすると、複数のユーザが受信した同報メールは、受信用メールサーバにおいて一元化され、ウイルスチェック１８６や電子メールアーカイブ１８２や、保留メールの保留解除や削除１８８を一元化して管理することができる。

１２．ユーザインターフェース
本実施形態のサーバは、Ｗｅｂサーバを併用しているので、端末のＷｅｂブラウザからの要求に応じて、ＨＴＴＰプロトコルを通じて、以下の情報を端末に送信すると共に、管理者やユーザから入力された情報を受信して、ルールの設定や、保留電子メールの処理、ＤＢの更新処理等を行うことができる。

（１）管理者用ＵＩ
管理者用ＵＩは、管理者からの入力に基づいて、ルール毎のスコアの設定や、顧客ＤＢ、社員ＤＢの追加、削除、更新処理、アクション履歴ＤＢの管理などを行う。

管理者用ＵＩでは、管理者からの入力に基づいて、ルールの有効、無効の設定、しきい値（自動配送しきい値、自動削除しきい値）の設定や、通知電子メールの編集、非通知保留処理の有効、無効の設定を行うことができる。

なお、管理者用ＵＩのＷｅｂページ（ＵＲＬ）へのアクセスは、管理者のみに権限が与えられる。つまり、ルール等の設定は管理者のみが行うことができるので、統一したルールに基づいて電子メールの保留処理を行うことができる。

（２）ユーザ用ＵＩ
ユーザ用ＵＩでは、社員ＤＢに登録されているユーザからの入力に基づくＷｅｂブラウザからの要求に応じて、ユーザ本人の保留された電子メールのＷｅｂページをユーザ端末に送信する処理を行う。またユーザ用ＵＩでは、ユーザからの保留電子メールに対する配送、削除のアクション指示を受け付けて、保留電子メールの配送、削除を行うことができる。また、ユーザからの入力に基づくＷｅｂブラウザからの要求に応じて、実行された保留電子メールのアクションの履歴を格納する処理を行う。また、ユーザ用ＵＩでは、ユーザからの入力に基づいて、顧客ＤＢにおいて会社名の新規登録や、署名の編集、ログイン時にパスワードの変更処理を行う。

本発明は、上述した実施形態及び具体例に限定されるものではなく、さらに種々の変形が可能である。例えば、本発明は、実施形態で説明した構成と実質的に同一の構成（例えば、機能、方法及び結果が同一の構成、あるいは目的及び効果が同一の構成）を含む。また、本発明は、実施形態で説明した構成の本質的でない部分を置き換えた構成を含む。また、本発明は、実施形態で説明した構成と同一の作用効果を奏する構成又は同一の目的を達成することができる構成を含む。また、本発明は、実施形態で説明した構成に公知技術を付加した構成を含む。

１０ サーバ、２０ 端末、２１ Ｗｅｂブラウザ、２２ ＭＵＡ、１００ 処理部、１１０ 電子メール処理部（ＭＴＡ）、１１１ 電子メール送信部、１１２ 電子メール受信部、１１３ 解析部、１１４ 識別情報生成部、１１５ メール一元化処理部、１１６ 暗号化処理部、１１７ 保留処理部、１１８ ウイルスチェック処理部、１１９ アーカイブ処理部、１２０ Ｗｅｂ処理部、１２１ 管理者用ＵＩ部、１２２ ユーザ用ＵＩ部、１３０ データベース処理部、１７０ 記憶部、１７１ 受信待ちテーブル、１７２ メール管理領域、１７３ 処理履歴格納領域、１７４ ルール格納領域、１７５ メールアーカイブ領域、１７６ パスワード格納領域、１７８ 各種ＤＢ

Claims (7)

1. 電子メールを受信して所与の処理を行うメールサーバのためのプログラムであって、
   差出元から送信された電子メールを受け付ける電子メール受信部と、
   受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する識別情報生成部と、
   所与の電子メールと他の電子メールが同じ識別情報を有する場合には、前記所与の電子メールのエンベロープ宛先と前記他の電子メールのエンベロープ宛先を含むエンベロープと、前記所与の電子メール又は前記他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行うメール一元化処理部と、してコンピュータを機能させるプログラム。
2. 請求項１において、
   前記メール一元化処理部は、
   所与の電子メール受信時に受信待ち期限を設定し、前記所与の電子メール受信時に設定した前記受信待ち期限内に、前記所与の電子メールと同じ識別情報を有する前記他の電子メールを受信した場合には、前記所与の電子メールと前記他の電子メールのメール一元化処理を行うプログラム。
3. 請求項１又は２において、
   電子メールの添付ファイルの暗号化処理を行い、暗号化ファイルとパスワードを生成する暗号化処理部と、してさらにコンピュータを機能させ、
   前記暗号化処理部は、
   所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルの暗号化処理済みのものがある場合には、前記他の電子メールの暗号化処理で生成したパスワードを用いて前記所与の電子メールの添付ファイルの暗号化処理を行うプログラム。
4. 請求項１乃至３のいずれかにおいて、
   電子メールの添付ファイルのウイルスチェック処理を行うウイルスチェック処理部と、してさらにコンピュータを機能させ、
   前記ウイルスチェック処理部は、
   所与の電子メールと同じ識別情報を有する他の電子メールに添付ファイルのウイルスチェック済みのものがある場合には、前記所与の電子メールのウイルスチェック処理を省略するプログラム。
5. 請求項１乃至４のいずれかにおいて、
   電子メールを保留し、所定の条件にしたがって保留した電子メールの配送または削除を行う保留処理部と、してさらにコンピュータを機能させ、
   前記保留処理部は、
   所与の電子メールと同じ識別情報を有する他の電子メールに配送処理または削除処理を行ったものがある場合には、前記所与の電子メールに、前記他の電子メールと同じ処理を行うプログラム。
6. 請求項１乃至５のいずれかにおいて、
   電子メールのアーカイブ処理を行うアーカイブ処理部と、してさらにコンピュータを機能させ、
   前記アーカイブ処理部は、
   所与の電子メールと同じ識別情報を有する他の電子メールにアーカイブ処理済みのものがある場合には、前記所与の電子メールのコピーは行わず、前記所与の電子メールのエンベロープ宛先をアーカイブ領域に格納した前記他の電子メールのエンベロープ宛先に追加するプログラム。
7. 電子メールを受信して所与の処理を行うメールシステムであって、
   差出元から送信された電子メールを受け付ける電子メール受信部と、
   受信した電子メールについて、当該電子メールのメッセージデータの通信経路に依存しない情報に基づき識別情報を生成する識別情報生成部と、
   所与の電子メールと他の電子メールが同じ識別情報を有する場合には、前記所与の電子メールのエンベロープ宛先と前記他の電子メールのエンベロープ宛先を含むエンベロープと、前記所与の電子メール又は前記他の電子メールのメッセージデータを含む電子メールを作成するメール一元化処理を行うメール一元化処理部と、を含むメールシステム。

Images