JPH09307584A - 電子メールシステム - Google Patents

Abstract

(57)【要約】 【課題】 窓口アドレスに対して送られたメールを複数
の担当者に転送した後、メールを読んだり返事を出した
担当者の管理が可能な電子メールシステムを提供する。 【解決手段】 メーリングリストサーバ２３が、メーリ
ングリストに送られて来たメール２１に対して必要なヘ
ッダを付加した後に、そのメッセージ２５をメンバ２８
にあててメールサーバ３４，３５に転送し、その、メッ
セージを受信したメールサーバ３４，３５は、メンバ２
８がメールを読んだ時に前述の付加されたヘッダを参照
し、通知アドレス２７にメッセージが読まれたこと及び
返事が送信されたことをメールメッセージとして送る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散ホストを相互
接続して構成されるネットワーク技術に関し、詳細に
は、ネットワーク上における電子メールの配送システム
に関する。

【０００２】

【従来の技術】従来、電子メールによるユーザサポート
窓口を設ける場合、メールアドレスとして代表アドレス
を設け、このアドレスに来たメールを複数の担当者に転
送する形で運用することが一般的である。そして、分散
ホストを相互接続して構成される広域ネットワーク上の
メールシステムでは、各担当者のメールボックスが複数
のメールサーバ上にある。

【０００３】

【発明が解決しようとする課題】しかしながら、複数の
担当者にメールを転送した場合、誰がそのメールを読ん
だか、あるいは誰が返事を出したか等を管理する必要が
ある場合、一台のホストで集中してメールを管理するシ
ステムではメールシステム自体にその機能を組み込むこ
とにより対応可能であるが、分散ホストによる広域ネッ
トワークにおいては、複数のメールサーバにメールが送
られるため、この情報を得ることが困難であった。

【０００４】本発明は、上述した問題点を解決するため
になされたものであり、窓口アドレスに対して送られた
メールを複数の担当者に転送した後、どの担当者がその
メールを読んだか、さらにはどの担当者がそのメールに
対して返事を出したかといった点を管理可能な電子メー
ルシステムを提供することを目的としている。

【０００５】

【課題を解決するための手段】この目的を達成するため
になされた本発明の電子メールシステムは、図１に例示
するように、基本構成として、分散ホストを相互接続し
て構成されるネットワーク上の分散ホストの一つとして
メールの送受信を行なう第１メールサービス手段及び同
じくメールの送受信を行なう第２メールサービス手段
と、ネットワークに接続されたユーザインターフェース
手段との３つの手段を備えており、２つのメールサービ
ス手段が、さらに以下のように構成されている。

【０００６】すなわち、前記第１メールサービス手段
は、メールの送受信を行なう第１のメール配送手段と、
制御用の付加情報をメールメッセージに付加するヘッダ
付加手段と、特定のメッセージが受取り人に読まれたこ
とを示す既読情報を記憶する第１の記憶手段とを備えて
いる。

【０００７】また、前記第２メールサービス手段は、メ
ールの送受信を行なう第２のメール配送手段と、このメ
ール配送手段によって受信されたメールを保持する第２
の記憶手段と、前記受信メールが前記ユーザインターフ
ェース手段によって読み出される際に、前記第１メール
サービス手段により付加されたヘッダ情報に従って、既
読通知を発信する既読通知手段とを備えている。

【０００８】本発明の電子メールシステムによれば、第
１メールサービス手段により付加されたヘッダに従っ
て、第２メールサービス手段が既読情報を第１メールサ
ービス手段に送信することにより、第１メールサービス
手段上で、メールの既読／未読の管理が容易に行なえ
る。そのため、窓口アドレスに対して送られたメールを
複数の担当者に転送した後、どの担当者がそのメールを
読んだかを管理することが容易にできる。

【０００９】また、請求項２に示すように、上述の構成
に加え、第１メールサービス手段又は第２メールサービ
ス手段の少なくともいずれか一方は、第１メールサービ
ス手段によって付加されたヘッダ情報を用いて特定のメ
ールに対する返信のメッセージを認識し、返信通知を発
信する返信通知手段を備え、さらに、第１メールサービ
ス手段がこの返信通知情報を第１の記憶手段に保持して
おくよう構成することも考えられる。

【００１０】この場合には、第１メールサービス手段に
より付加されたヘッダに従って、第１メールサービス手
段又は第２メールサービス手段が特定のメールに対する
返信のメッセージを認識することが可能であり、このヘ
ッダの内容に従って返信通知を第１メールサービス手段
に送信することによって、第１メールサービス手段上で
特定のメールに対する返信がなされたか否かが容易に管
理できる。そのため、上述の複数担当者に転送した後で
どの担当者がそのメールを読んだかに加えて、さらに、
どの担当者がそのメールに対して返事を出したかを管理
することが容易にできる。なお、返信通知のみの管理は
現実的でない。それは、メールを読んだ結果として返信
を実行するからである。

【００１１】また、請求項３に示すように、ユーザイン
ターフェース手段が、第２メールサービス手段からメッ
セージを読み出す際に、第１メールサービス手段によっ
て付加されたヘッダ情報に従って既読通知情報を発信す
る既読通知手段と、読み出したメールに対する返信の際
に、第１メールサービス手段によって付加された情報に
従って返信通知を発信する返信通知手段との２つの手段
の内の少なくともいずれか一方を備えるようにしてもよ
い。

【００１２】この場合には、第１メールサービス手段に
より付加されたヘッダに従って、ユーザインターフェー
ス手段においても既読情報及び返信情報の少なくとも一
方を第１メールサービス手段に通知することが可能であ
り、この情報を用いることで第１メールサービス手段で
は、さらにきめ細かくメッセージが管理することができ
る。

【００１３】そしてまた、請求項４に示すように、第１
メールサービス手段が、受信したメール中のコマンドを
認識し、そのコマンドに従って第１の記憶手段中の既読
情報及び返信情報をメール差し出し人に返信するコマン
ド実行手段を備えるようにしてもよい。この場合には、
第１メールサービス手段にメールによるコマンド実行手
段が用意されているので、問い合わせのメールを第１メ
ールサービス手段に送れば、容易に既読情報及び返信情
報を入手できることとなる。

【００１４】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して説明する。本実施形態の電子メールシ
ステムは、図３に示す分散ネットワーク上のメールシス
テムとして実現される。このシステムは、ネットワーク
３１に接続された複数のサーバ２３，３２，３３，３
４，３５と、端末３６から構成されている。なお、図３
では複数のサーバとして、１台のメーリングリストサー
バ２３と１台の中継サーバ（Ｄ）３３と、３台のメール
サーバ（Ａ，Ｂ，Ｃ）３２，３４，３５とが示されてい
る。以下の説明では、これらをまとめて指す場合には単
に「サーバ」と呼び、区別して指す場合には個別名（メ
ールサーバＡ等）で示すこととする。

【００１５】メールメッセージは、各サーバ２３，３
２，３３，３４間でやり取りされ、各利用者（メンバ
Ａ，Ｂ，Ｃ）３７，３８，３９は、端末３６を介してア
クセスすることでメールの送受信を行なう。本発明の基
礎となるのは、このシステム上で動作するメーリングリ
ストであるので、以下の説明に先だって、このメーリン
グリストについて説明する。

【００１６】メーリングリストとは、図４の概念図に示
すように、複数のユーザ４６，４７，４８（メーリング
リストのメンバと呼び、ここではそれぞれＡ，Ｂ，Ｃで
示す。なお、図４では概念説明のために用いたものであ
り、図３のメンバとの対応は取っていない。）に対して
代表となるメールアドレス（以下、代表アドレスと呼
ぶ。）４１を用意し、その代表アドレス４１に来たメー
ルを、登録されているメンバ（Ａ，Ｂ，Ｃ）４７，４
８，４９に転送するしくみである。

【００１７】例えば、［ｓｕｐｐｏｒｔ＠ｄｅｆ．ｈｉ
ｊ］という代表アドレス４１を持つメーリングリスト
に、メンバとしてＡ〜Ｃの３人のメールアドレスが登録
されている場合には、この代表アドレス［ｓｕｐｐｏｒ
ｔ＠ｄｅｆ．ｈｉｊ］にメールが来ると、配送システム
４２はメンバリスト４４から各メンバ（Ａ〜Ｃ）のメー
ルアドレスを取り出し、そのリスト中の全メンバにメー
ルを配送する。

【００１８】メーリングリストの基本機能は、このよう
に、複数のユーザに対する代表アドレスを提供するとい
うことであるが、その他に、以下の〜の機能があ
る。 アーカイブ機能…メーリングリストに送られて来たメ
ールを、メッセージ保存部４３にファイルとして保存す
る。

【００１９】ヘッダの書き換え…メーリングリストに
送られて来たメールに通し番号を振ったり、返事を書く
場合の返事のあて先として、元の発信人個人のアドレス
ではなく、メーリングリストのアドレスになるようなヘ
ッダを付加する。 メールによるコマンドの実行…メーリングリストにメ
ールでコマンドを送ると、コマンド実行部４５はコマン
ドに従って、アーカイブされたメールをメッセージ保存
部４３から取り出したり、メンバリスト４４を変更する
ことによりメンバの登録、削除を行なう。

【００２０】さて、図３に示す本実施形態の分散ネット
ワークにおけるメーリングリストでは、メーリングリス
トのプログラムが動作しているメーリングリストサーバ
２３と、各担当者のメールの受け取り先となっているメ
ールサーバ（Ｂ，Ｃ）３４，３５は、異なるホストであ
る。

【００２１】そのため、メーリングリストをユーザサポ
ート窓口に利用した場合、メーリングリストサーバ２３
から各担当者のメールサーバ（Ｂ，Ｃ）３４，３５にメ
ールは送れても、メールサーバ（Ｂ，Ｃ）３４，３５内
部の情報は利用できない。そのため、どの担当者がメー
ルを読んだか、また、どの担当者が返事を出したかはメ
ーリングリストサーバ２３では管理できなかった。

【００２２】本電子メールシステムの目的は、この様な
場合に誰がメールを読んだか、そして返事を出したかを
管理できるようにすることでであり、その具体的な実現
方法を以下に詳細に説明する。本実施形態においては、
図２の機能構成図に示すように、メーリングリストサー
バ２３が、メーリングリストに送られて来たメール２１
に対して必要なヘッダを付加した後に、そのメッセージ
２５をメンバ２８にあててメールサーバ３４，３５に転
送することと、メールを受信したメールサーバ３４，３
５が、メーリングリストのメンバ２８がメールを読んだ
時にメーリングリストサーバ２３によって付加されたヘ
ッダを参照し、通知アドレス２７にメッセージが読まれ
たこと及び返事が送信されたことをメールメッセージと
して送る点が特徴となっている。

【００２３】従って、本実施形態においては、メーリン
グリストサーバ２３と、既読／返信情報を送信するメー
ルサーバ３４，３５の二つが、主要な要素となってい
る。次に、この二つの要素の構成を示す。まず、メーリ
ングリストサーバ２３について説明する。

【００２４】メーリングリストサーバ２３は本発明にお
ける「第１メールサービス手段」に相当し、周知のコン
ピュータを中心として構成され、主たる動作はそのコン
ピュータ上で動作するプログラムとして実現されてい
る。その構成は、図５に示すように、「ヘッダ付加手
段」や「返信通知手段」に相当するメッセージ管理部５
３を処理機能の中心とし、ネットワークインターフェー
ス５１から受信したメールを「第１のメール配送手段」
に相当するメール配送部５２を経由して受け取り、ヘッ
ダの付加５５などの処理を行った後、メーリングリスト
の各参加メンバに対してメッセージを送ることができる
ようにされている。各メールは、メール配送部５２によ
って各メンバに対応した送り先サーバが決定され、ネッ
トワークインターフェス５１によって送信される。ま
た、メッセージ管理部５３では、メンバの管理５６やヘ
ッダの解析５７等も行なわれる。

【００２５】各メンバ及びメッセージに関する情報は、
「第１の記憶手段」に相当する記憶装置５４に保持され
ており、メッセージ管理部５３からの指示に従って、読
み出し変更が行われる。また、記憶装置５４中には、メ
ッセージの内容及びメッセージが各メンバによって読み
出されたかを示す既読情報と、返事が出されたかを示す
返信通知情報が記憶されている。

【００２６】この記憶装置５４の記憶内容を図６に示
す。受信したメッセージは、全てｍｅｓｓａｇｅｓディ
レクトリ６１中にファイル６２の形で記憶される。各メ
ッセージは受信順の番号（０００１，０００２，……）
が付けられ、その番号がファイル名となっている。ま
た、メンバのアドレスを保持しているメンバリストは、
各メンバのメールアドレスを列挙したｍｅｍｂｅｒｓフ
ァイル６３の形で保持されている。

【００２７】本発明の特徴である既読情報や返信情報
は、この記憶装置５４においてはｕｓｅｒｓディレクト
リ６４内の、さらに各メンバ毎に作られたユーザディレ
クトリ６５中に保持される。このユーザディレクトリ６
５中に、既読情報を示すｒｅａｄファイル６６と、ｒｅ
ｐｌｙファイル６７を用意し、このファイルに既読及び
返信を行なったメッセージの番号（０００１，０００２
等）を記録する。

【００２８】次に、メールサーバ３２，３４，３５につ
いて説明する。なお、本実施形態においては、メールサ
ーバ３２，３４，３５の内、メンバ（Ｂ，Ｃ）３８，３
９に接続されているメールサーバ（Ｂ，Ｃ）３４，３５
が本発明における「第２メールサービス手段」に相当す
る。

【００２９】メールサーバ３２，３４，３５は、送られ
て来たメールメッセージをネットワークインターフェー
ス７１を介して取得し、「第２のメール配送手段」に相
当するメール配送部７２によって送信先を決定する。こ
の送信先が当該メールサーバ３２，３４，３５上のユー
ザの場合は、そのメッセージを「第２の記憶手段」に相
当する記憶装置７４中に保存し、後にユーザが端末３６
（図３参照）から当該メールサーバ３２，３４，３５に
アクセスして、そのメールを読む。

【００３０】また、送信先が、他のメールサーバ３２，
３４，３５である場合は、メール配送部７２によって再
送信先が決定され、ネットワークインターフェース７１
を介して他のメールサーバ３２，３４，３５に転送され
る。また、「既読通知手段」や「返信通知手段」に相当
するメッセージ管理部７３では、メッセージ中のヘッダ
を処理するためのヘッダ処理７５や、新たなメッセージ
を作成するためのメッセージ生成７６等も行われる。こ
の電子メールシステムで扱うメッセージのフォーマット
やメッセージの転送プロトコルとしては、インターネッ
ト等で既に利用されている周知のものを用いればよく、
本案の特徴ではないので、ここでの説明を省略する。

【００３１】さて、次に本実施形態の利用例の状況を説
明する。図３に示す分散ネットワーク上のメールシステ
ムにおいて、メーリングリストサーバ２３上でメーリン
グリストプログラムが動作しており、メーリングリスト
名として、［ｓｕｐｐｏｒｔ＠ｄｅｆ．ｈｉｊ］という
アドレスが割り当てられている。また、メンバとして、
２つのメールサーバ（Ｂ，Ｃ）３４，３５上のユーザが
登録されている。また、メールサーバ（Ａ）３２上に
は、メンバではないユーザ（Ａ）３７が接続されてい
る。

【００３２】さて、このシステムで、「ユーザ（Ａ）３
７からメーリングリストにメールが出され、そのメール
がメンバ（Ｂ，Ｃ）３８，３９に転送される。その後、
メンバ（Ｃ）３９がメールを読み、ユーザ（Ａ）３７に
返事を書く。その後、メンバ（Ｂ）３８がメールを読
み、返事が出されたかどうかを確認するため、メーリン
グリストサーバ２３に問い合わせのメールを出し、その
返事を受け取る」という状況を想定して以下の説明を進
める。

【００３３】まず、ユーザ（Ａ）３７がメーリングリス
トに対してメールを送信する。この時には、メールサー
バ（Ａ）３２を介してメーリングリストサーバ２３にメ
ッセージが送られる。メーリングリストサーバ２３で
は、このメールのあて先が、メーリングリストあてであ
るので、そのメーリングリストを各メンバ（Ｂ，Ｃ）３
８，３９に配送する。

【００３４】このときのメーリングリストサーバ２３で
の処理手順を図９のフローチャートを参照して説明す
る。最初のステップ８０１（以下ステップをＳで示
す。）にてメーリングリストサーバ２３のメッセージ管
理部５３がメールを受け取ると、メッセージに番号を付
け（Ｓ８０２）、記憶装置５４中に保存する（Ｓ８０
３）。メッセージは、この番号を名前とするファイルと
して記憶される。

【００３５】次に、メッセージ管理部５３は、送られて
来たメッセージにヘッダを追加する（Ｓ８０４）。ヘッ
ダには、メーリングリストの名前や、［Ｆｒｏｍ：］ヘ
ッダなどの一般的なヘッダがあるが、本案の場合には、
既読・返信の連絡先を示す［Ｘ−ｎｏｔｉｆｙ−ｒｅｃ
ｅｉｖｅ−ｒｅｐｌｙ：］ヘッダを付加することが特徴
となっている。このヘッダには、図８に示すように、メ
ンバがメールを読んだり返事をした際に、そのことを通
知する先のメールアドレス９１が入っている。

【００３６】このアドレスとしては、当該メーリングリ
ストのサーバで、メーリングリストのアドレス名とは異
なる名前が用いられる。本実施形態では、例えば［ｓｕ
ｐｐｏｒｔ−ｎｏｔｉｆｙ＠ｄｅｆ．ｈｉｊ］になる。
次に、メッセージ管理部５３は記憶装置５４からメンバ
リスト６３（図６参照）を取り出し（Ｓ８０５）、リス
ト中の全メンバに対して、前述のヘッダを追加したメッ
セージを送信する（Ｓ８０６，Ｓ８０７）。

【００３７】メーリングリストサーバ２３から送信され
たメールは、各メンバのサーバに送られる。メッセージ
が各メンバのサーバに届いた後、メンバ（Ｃ）３９がメ
ールを読むためにメールサーバ（Ｃ）３５にアクセスす
ると、そのメールサーバ（Ｃ）３５では、図１０に示す
処理を実行する。

【００３８】端末３６からアクセス待ち（Ｓ１００１）
の後、ユーザ名を特定し（Ｓ１００２）、ユーザあてメ
ッセージがあった場合には（Ｓ１００３：ＹＥＳ）、そ
のユーザへのメッセージを取り出す（Ｓ１００４）。そ
して、そのメッセージ中のヘッダをチェックして既読通
知要求ヘッダ［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒ
ｅｐｌｙ：］があれば（Ｓ１００５：ＹＥＳ）、そのヘ
ッダから通知先を取り出し（Ｓ１００６）、そのアドレ
スに対してメールが読まれたことを示す既読通知メール
を送信する（Ｓ１００７）。また、同時に、このメール
の［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダに入っているメッ
セージＩＤと、［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−
ｒｅｐｌｙ：］のヘッダ対を保存しておく（Ｓ１００
８）。これは、後述する返信通知のためである。

【００３９】その後、端末３６側にメッセージを送信す
る（Ｓ１００９）。この処理をユーザあての全てのメッ
セージについて行なう（Ｓ１００３）。なお、この既読
通知のメールは、図８に示す［Ｓｕｂｊｅｃｔ：］ヘッ
ダ９３に、「Ｒｅａｄ メッセージ番号（←図８では０
００６） メンバのメールアドレス」が入っているだけ
で本文のないメールである。

【００４０】このメールは、メーリングリストサーバ２
３に転送される。メーリングリストサーバ２３内のメッ
セージ管理部５３（図５参照）はこのメールを受け取る
と、既読情報を更新する。メッセージ管理部５３は、
［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］
ヘッダ９１を持つメッセージを受信したとき、該当する
メンバのユーザディレクトリ６５中のｒｅａｄファイル
６６（図６参照）にメッセージ番号を追加する。

【００４１】さて、次にメンバ（Ｃ）３９が受信したメ
ールに対して返事を出す場合の動作について説明する。
既読通知については、メールサーバ３２，３４，３５側
だけで処理が可能であるが、返信通知については、返信
のメールがどのメールに対する返事であるかを直接知る
ことができない。そこで、本実施形態においては、次の
３つの方法を用意し、適宜選択して使用する。

【００４２】１つ目の方法は、端末３６上で動作するメ
ールユーザインターフェースプログラム（以下、「メー
ラー」と呼ぶ。）に返信確認メールを出す機能を追加す
ることで実現する。メーラーを用いて返事を出す際に、
元のメールに［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒ
ｅｐｌｙ：］ヘッダが含まれていた場合、その内容を用
いて、返信メールを出す時、同時に返信確認メールをメ
ーリングリストサーバ２３に対して送ることで返信の確
認ができる。

【００４３】この方法では、メンバが使用する端末３６
上のメーラー全てにこの機能を持たせることが必要とな
るが、返信先によらず、全ての返信メールをチェックす
ることが可能である。２つ目の方法は、返信通知機能を
端末３６ではなく、メールサーバ３２，３４，３５に組
み込む方法である。この方法では、全ての端末３６に機
能を追加する必要はなくなる。この第２の方法では、返
信メールに一般的に含まれている［Ｒｅｆｅｒｅｎｃｅ
ｓ：］ヘッダをメールサーバ３２，３４，３５側でチェ
ックして返信メールであることを検出し、返信通知メー
ルを出す。一般的に、メーラーが返信を行なう際には、
元のメールの［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダの内容
を［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダとして付加するの
で、これを利用して、返信通知の必要なメールであるか
をチェックする。

【００４４】この第２の方法の詳細を以下に示す。これ
までにも述べたように、メンバ３８，３９がメールサー
バ３４，３５からメールを読み出す際に、メールサーバ
３４，３５側では、［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダ
と、［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌ
ｙ：］ヘッダの対をメールサーバ３４，３５内部の記憶
装置７４（図７参照）に記憶しておく。

【００４５】メンバ（Ｂ，Ｃ）３８，３９が、このメー
ルに対して返信し、その返信メールがメールサーバ３
４，３５に送られると、メールサーバ３４，３５は、図
１１に示す返信通知処理を実行する。まずメールメッセ
ージを受信し（Ｓ１１０１）、その受信したメールメッ
セージに対して、その返信メールの［Ｒｅｆｅｒｅｎｃ
ｅｓ：］ヘッダをチェックする（Ｓ１１０２）。ヘッダ
が存在すれば（Ｓ１１０３：ＹＥＳ）、メールサーバ３
４，３５内に保存されているメッセージから上述のヘッ
ダ対を取り出し（Ｓ１１０４）、［Ｍｅｓｓａｇｅ−Ｉ
Ｄ：］ヘッダと、返信メールの［Ｒｅｆｅｒｅｎｃｅ
ｓ：］ヘッダとを比較する（Ｓ１１０５）。

【００４６】そして、一致するものがあった場合は（Ｓ
１１０６：ＹＥＳ）、そのメールに対する返信であると
判断して、［Ｍｅｓｓａｇｅ−ＩＤ：］と対で保持して
いる［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌ
ｙ：］の内容を取り出し（Ｓ１１０９）、そのアドレス
に返信通知メールを送信する（Ｓ１１１０）。その後、
通常通りメールメッセージを返信先に送信する（Ｓ１１
０８）。なお、ヘッダ対が一致していない場合には（Ｓ
１１０６：ＮＯ）、全てのヘッダ対についての比較が終
了するまで実行し（Ｓ１１０７）、それでも一致するも
のがない場合は（Ｓ１１０７：ＹＥＳ）、Ｓ１１０８へ
移行する。

【００４７】一般に、ユーザ３８，３９がメールを出す
場合は、メールサーバ３４，３５を経由するので、この
第２の方法でも、返信のあて先によらず返信チェックが
可能である。また、この方式は、各メンバ３８，３９に
対応するメールサーバ３４，３５上だけでなく、メーリ
ングリストサーバ２３でも実現可能である。従って、３
つ目の方法としては、メーリングリストサーバ２３上で
上記の方法を用いることが考えられる。メーリングリス
トでは、メーリングリストから各メンバに対して送られ
たメールに対する返信もメーリングリストにすることが
一般的である。これは、メーリングリストに来たメール
は全メンバに転送されるので、それに対する返事もメー
リングリストのメンバ全てに送ることが自然なためであ
る。

【００４８】そのため、メーリングリストサーバ２３で
は、メンバに転送するメッセージの［Ｒｅｐｌｙ−Ｔ
ｏ：］ヘッダに、メーリングリスト自身のアドレスを入
れている。そのため、メーリングリストからのメッセー
ジに対して返信を行なった場合、その返信メールは、差
し出し人あてではなく、メーリングリストあてとなる。
そして、メーリングリストのメンバ全員が返事を受け取
れるようになっている。従って、メーリングリストあて
のメールに対する返事は、メーリングリストサーバ２３
を経由するので、メーリングリストサーバで上記の［Ｒ
ｅｆｅｒｅｎｃｅｓ：］ヘッダをチェックすることによ
り、返信通知が行なえる。この方法では、メーリングリ
ストあてでないメールについては返信はチェックできな
いが、全ての処理をメーリングリストサーバで行なえる
ので、実現が容易である。

【００４９】ところで、これまでの手順によって、メー
リングリストサーバ２３上にはメールが読まれたかどう
かを示す既読情報と返信されたかどうかを示す返信通知
情報が保持されている。そのため、次に、メンバＢが確
認のためこの情報を取り出す手順について説明する。

【００５０】メーリングリストに対して、通常のメール
を送るのではなく、特別な動作をさせるためには、コマ
ンドメールと呼ばれるメールをメーリングリストに対し
て送ることにより実現されている。既読／返信の確認に
ついても、このコマンドメールを用いる。コマンド・メ
ールにはいくつかの方式があるが、ここでは、メールの
ヘッダにコマンドを記入する方法を用いる。

【００５１】このときに送られるコマンドは、返信通知
のチェックであることを示す文字列と、返信通知情報の
チェック対象となるメッセージの番号を［Ｘ−ＭＬ−Ｃ
ｏｍｍａｎｄ：］ヘッダ９２（図８参照）に入れたもの
である。例えば、「Ｘ−ＭＬ−Ｃｏｍｍａｎｄ： ｃｈ
ｅｃｋ ｒｅｐｌｙ ２０」というメールをメーリング
リストに送信すると、メーリングリストプログラムがコ
マンドを実行し、その結果をコマンドメールの発信者に
返送する。

【００５２】この手順を図１２のフローチャートを参照
して説明する。メーリングリストサーバ２３がコマンド
メールを受信すると、その［Ｘ−ＭＬ−ｃｏｍｍａｎ
ｄ：］ヘッダ９２（図８参照）からコマンドを取り出す
（Ｓ１２０１）。次にこのコマンドがｃｈｅｃｋコマン
ドであるかどうかを調べる（Ｓ１２０２）。ここでは、
ｃｈｅｃｋコマンド以外の場合は、そのコマンドに対応
した適宜しかるべき処理を行なう（Ｓ１２１１）ものと
して、その詳しい内容の説明は省略する。

【００５３】一方、ｃｈｅｃｋコマンドの場合は（Ｓ１
２０２：ＹＥＳ）、そのコマンドが既読通知である「ｒ
ｅａｄ」であるか（Ｓ１２０３）、返信通知である「ｒ
ｅｐｌｙ」であるか（Ｓ１２０４）に従って、処理を振
り分ける。返信通知のｒｅｐｌｙの場合（Ｓ１２０４：
ＹＥＳ）、［Ｘ−ＭＬ−Ｃｏｍｍａｎｄ：］ヘッダ９２
からメッセージ番号を取り出し（Ｓ１２０５）、この番
号が各メンバのディレクトリ中のｒｅｐｌｙファイル６
７（図６参照）にあるかどうかサーチする（Ｓ１２０
６）。もし、番号がｒｅｐｌｙファイル６７中にあれ
ば、そのメンバが返信メールを出したことになるので、
そのユーザ名を結果とする（Ｓ１２０８）。そして、全
てのメンバについて上記のチェックが終了すると（Ｓ１
２０９：ＹＥＳ）、結果をコマンド・メールの送信者に
返信する。

【００５４】一方、既読通知のｒｅａｄの場合（Ｓ１２
０３：ＹＥＳ）は、Ｓ１２１２〜Ｓ１２１６の処理を実
行するが、これは上記ｒｅｐｌｙの場合のＳ１２０５〜
Ｓ１２０９の処理と同様なので、詳しい説明は省略す
る。そして、この場合も、全てのメンバについてチェッ
クが終了すると（Ｓ１２１６：ＹＥＳ）、結果をコマン
ドメールの送信者に返信して本処理を終了する。これで
メールを読んだメンバのリストが得られる。

【００５５】なお、この図１２のフローチャートが本発
明の「コマンド実行手段」としての処理の実行に相当す
る。このように、本電子メールシステムを用いること
で、これまで不可能であった分散メールシステム上での
既読、返信の確認が可能となり、メッセージの管理をき
め細かく行なうことができる。そのため、窓口アドレス
に対して送られたメールを複数の担当者に転送した後、
どの担当者がそのメールを読んだか、そしてどの担当者
がそのメールに対して返事を出したかを管理することが
容易にできる。

【００５６】また、全ての操作をメールにより行なえる
ので、ユーザが特別な装置・ソフトウェアを準備する必
要がなく、実現が容易である。以上、本発明はこのよう
な実施例に何等限定されるものではなく、本発明の主旨
を逸脱しない範囲において種々なる形態で実施し得る。

【００５７】例えば、上記実施形態においては、端末３
６側では返信情報のみを扱っていたが、既読通知につい
ても端末３６側でヘッダを見て送信することができる。
もちろん、この場合は、全ての端末３６にそのための処
理が必要である。また、メーリングリストのシステムに
限らず、受信側のメールサーバに既読通知の機能があれ
ば、発信者が直接ヘッダを付加することで、既読情報を
得ることが可能である。

【００５８】また、このシステムでは、既読情報を保持
しているが、実際には、メンバは全てのメールを読むは
ずなので、既読情報ではなく、未読情報を保持する方が
利用の上では便利である。また、実際に運用する場合に
は、管理用にいくつかの処理の追加が望まれる。たとえ
ば、前記既読情報及び返信情報は、増える一方なので、
定期的に消す必要がある。そのためには、メッセージに
含まれている［Ｄａｔｅ：］ヘッダを記録しておき、こ
の日付からある一定の期間を過ぎた既読情報や、返信情
報に用いる［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダ、及び
［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］
ヘッダの対を消すことにより対応できる。

【図面の簡単な説明】

【図１】 本発明の構成を例示する説明図である。

【図２】 本発明の実施形態の概要を示す機能構成図で
ある。

【図３】 本発明が実現される分散ネットワーク上の電
子メールシステムの概略構成図である。

【図４】 メーリングリストの概念説明図である。

【図５】 メーリングリストサーバの概略構成図であ
る。

【図６】 メーリングリストサーバの記憶装置の内容を
示す説明図である。

【図７】 メールサーバの概略構成図である。

【図８】 メールのヘッダの概略構成図である。

【図９】 メーリングリストの基本処理手順を示すフロ
ーチャートである。

【図１０】 メールサーバにて実行される既読通知処理
手順を示すフローチャートである。

【図１１】 メールサーバにて実行される返信通知処理
手順を示すフローチャートである。

【図１２】 メーリングリストサーバにて実行されるコ
マンドメールの処理手順を示すフローチャートである。

【符号の説明】

２３…メーリングリストサーバ ３１…ネット
ワーク ３２…メールサーバＡ ３３…中継サ
ーバＤ ３４…メールサーバＢ ３５…メール
サーバＣ ３６…端末 ３７…ユーザ
Ａ ３８…メンバＢ ３９…メンバ
Ｃ ５１…ネットワークインターフェース ５２…メール
配送部 ５３…メッセージ管理部 ５４…記憶装
置 ７１…ネットワークインターフェース ７２…メール
配送部 ７３…メッセージ管理部 ７４…記憶装
置

Claims (4)

【特許請求の範囲】
1. 【請求項１】 分散ホストを相互接続して構成されるネ
   ットワークにおける前記分散ホストとして構成され、メ
   ールの送受信を行なう第１メールサービス手段及び同じ
   くメールの送受信を行なう第２メールサービス手段と、 前記ネットワークに接続され、前記第２メールサービス
   手段からメールを読み出すユーザインターフェース手段
   とを備えた電子メールシステムにおいて、 前記第１メールサービス手段は、 メールの送受信を行なう第１のメール配送手段と、制御
   用の付加情報をメールメッセージに付加するヘッダ付加
   手段と、特定のメッセージが受取り人に読まれたことを
   示す既読情報を記憶する第１の記憶手段とを備え、 前記第２メールサービス手段は、 メールの送受信を行なう第２のメール配送手段と、この
   メール配送手段によって受信されたメールを保持する第
   ２の記憶手段と、前記受信メールが前記ユーザインター
   フェース手段によって読み出される際に、前記第１メー
   ルサービス手段により付加されたヘッダ情報に従って、
   既読通知を発信する既読通知手段とを備えることを特徴
   とする電子メールシステム。
2. 【請求項２】 前記第１メールサービス手段又は前記第
   ２メールサービス手段の少なくともいずれか一方は、前
   記第１メールサービス手段によって付加されたヘッダ情
   報を用いて特定のメールに対する返信のメッセージを認
   識し、返信通知を発信する返信通知手段を備え、 さらに、前記第１メールサービス手段は、この返信通知
   情報を前記第１の記憶手段に保持しておくよう構成され
   ていることを特徴とする請求項１に記載の電子メールシ
   ステム。
3. 【請求項３】 前記ユーザインターフェース手段は、 前記第２メールサービス手段からメッセージを読み出す
   際に前記第１メールサービス手段によって付加されたヘ
   ッダ情報に従って前記既読通知情報を発信する既読通知
   手段、及び、前記読み出したメールに対する返信の際に
   前記第１メールサービス手段によって付加された情報に
   従って前記返信通知を発信する返信通知手段の少なくと
   もいずれか一方を備えることを特徴とする請求項１又は
   ２に記載の電子メールシステム。
4. 【請求項４】 前記第１メールサービス手段は、 前記受信したメール中のコマンドを認識し、そのコマン
   ドに従って前記第１の記憶手段中の既読情報及び返信情
   報をメール差し出し人に返信するコマンド実行手段を備
   えることを特徴とする請求項１〜３のいずれかに記載の
   電子メールシステム。