JP2007287000A - 同報通信プログラム - Google Patents

Abstract

【課題】同報通信を行う際、同報通信宛先の複数の送信先から一部を除外できるようにすること。
【解決手段】本発明では、クライアント１０側において複数の送信先のリストとなる同報通信宛先（例えば、メーリングリスト）と同報通信宛先のうち除外する送信先（例えば、メールアドレス）とをヘッダとして受け付け、送信対象の情報とともにサーバ２０に送信する。また、サーバ２０では、クライアント１０から送られた同報通信の情報の中からヘッダを読み取り、同報通信宛先の複数の送信先の中から除外する送信先がある場合にはその送信先以外の送信先にクライアント１０から送られた情報を送信する。
【選択図】図１

Description

本発明は、複数の宛先に同時に情報送信を行う同報通信プログラムに関し、特に情報送信を行うクライアントならびにサーバで実行されるものに関する。

従来、同報通信（メーリングリスト）の利用では、１つのメールアドレスに対してメールを送信することにより、そのメーリングリストの参加者全員に同報することができる。しかし、特別なケースにおいては、参加者全員ではなく、特定の参加者には送信できないようにしたい場合もある。この場合においては、従来技術として、以下のような方法が考えられている。

（１）送信したくない参加者を除いた他の参加者の一人一人のメールアドレスを宛先リストに追加して送信する方法。
（２）メール送信者がメーリングリストの参加者アドレス情報をメーリングリスト管理サーバから取得し、その中から送信したい相手を選択して送信する方法（特許文献１参照）。
（３）拡張ヘッダに送信したい、または送信したくない参加者のアドレスを指定することにより、メーリングリストを利用するものの特定の参加者にのみメール本文と添付ファイルを配信し、その以外の参加者にメール本文と添付ファイルに関する情報を配信する方法（特許文献２参照）。

特開２００１−１５６８２９号公報 特開２００４−１２７０６５号公報

しかしながら、上記（１）の方法では、メーリングリストのサービスを利用できず、一人一人のメールアドレスを宛先リストに追加しなければならないので、大変手間がかかってしまう。

また、上記（２）の方法では、メーリングリストの管理サーバからメーリングリストの参加者アドレスリストを取得しその中から選択することにより宛先リスト（Toヘッダ）へのアドレスを追加する手間を低減できることをポイントとしているが、まずメーリングリストサーバがすべての参加者のアドレス情報を開示することについてセキュリティ上の問題がある。さらに、わざわざサーバから取得しなくても、ローカルのメールソフトのアドレス帳などには、メーリングリストの参加者のアドレス情報をすべて保持しておりアドレス帳から選択すれば同じことが実現できる。結局、宛先リスト（Toヘッダ）に送信したい相手のメールアドレスを追加するという意味では、やはり本来のメーリングリストの同報サービスを利用できずに、本質的には上記（１）の方法と変わっていない。

また、上記（３）の方法では、添付ファイルを特定の相手に送信するか否かを実現することを目的としているので、情報そのものの送信について制御する構成ではない。また、メールの受信側は拡張ヘッダをどう扱うかについては言及しておらず、拡張ヘッダに指定されていた情報は、メールの送信者と受信者の間では共有できず、どの参加者が除外されたのかという送信側の意図が分からず、例えば返信する際に本来メールの送信者が除外した参加者と異なる参加者を指定しまうといった行き違いが発生しやすく、情報漏れの恐れもある。

本発明はこのような課題を解決するために成されたものである。すなわち、本発明は、同報通信を行うサーバに対してネットワークを介して情報送信を行うクライアントで実行される同報通信プログラムにおいて、複数の送信先のリストとなる同報送信宛先を受け付けるステップと、同報送信宛先の複数の送信先の中から除外する送信先を受け付けるステップと、受け付けた同報通信宛先と除外する送信先とをヘッダに格納して送信対象の情報とともにサーバに送信するステップとを備えている。

このような本発明では、クライアントユーザが同報通信を行う際に送信対象の情報に同報通信宛先を指定するとともに、同報通信宛先の複数の送信先の中から除外したい送信先を指定する。この同報通信宛先と除外したい送信先はヘッダとして格納され、情報とともにサーバへ送信される。クライアントユーザは、通常の同報通信と同じ宛先指定とともに、除外した宛先がある場合にはその宛先だけを指定すれば良いことになる。

また、本発明は、クライアントから送られた同報通信の情報を受け付けて所定の送信宛先に当該情報を送信するサーバで実行される同報通信プログラムにおいて、クライアントから送られた同報通信の情報の中からヘッダを読み取り、同報通信宛先の複数の送信先の中から除外する送信先があるか否かを判断するステップと、除外する送信先がない場合には同報通信宛先の複数の送信先の全てにクライアントから送られた情報を送信し、除外する送信先がある場合には同報通信宛先の複数の送信先の中の除外する送信先以外の送信先にクライアントから送られた情報を送信するステップとを備えるものである。

このような本発明では、クライアントユーザから送信された同報通信の情報のヘッダに、同報通信宛先から除外する送信先が含まれている場合、同報通信宛先の示す複数の送信先のうち除外する送信先以外の送信先のみに情報を送信する。これにより、同報通信をベースとしつつ、その中の一部の宛先のみを除外して情報を送信することができる。

具体的には、メーリングリストにおいて特定の参加者を除外する場合、クライアントユーザはメーラの宛先ヘッダにメーリングリストアドレスを入力するとともに、拡張ヘッダに用意された除外アドレス指定枠に除外するアドレスを入力する。これにより、メーリングリストの同報サービスを利用できるとともに、特定の参加者を除外し、他の参加者にメールの同時送信を実現できる。

また、本発明では、除外したい参加者のアドレス情報を格納しているメール拡張ヘッダを受信側に提示することにより、特定参加者を除外しメールを送信したメール送信者の意図が明確に受信側に反映され、この情報の共有により、受信者が返信する際に除外した参加者へ返信されないようにすることができる。

したがって、本発明によれば、送信情報のヘッダを拡張することにより、宛先ヘッダ（ToヘッダやCcヘッダ）に送信先を追加するのと同じ操作で、拡張ヘッダに送信したくない宛先を追加するだけの簡単な操作で、同報通信を利用した際に、特定の宛先に送信しないようにするシステムを実現することが可能となる。

以下、本発明の実施の形態を図に基づき説明する。図１は、本実施形態に係る同報通信プログラムの実現方法を説明する模式図である。本実施形態の同報通信プログラムは、クライアント１０からネットワークを介してサーバ（例えば、メールサーバ２０）に同報通信を行い、サーバから同報通信宛先へ同時に情報を発信するシステムで実行されるもので、特に本実施形態の同報通信プログラムは、クライアント１０側で実行されるものと、サーバで実行されるものとに分けられる。

（処理の概要）
本実施形態における同報通信プログラムの処理の概要を以下に説明する。図１に示す例では、同報通信宛先としてsample-me@sample.comが用意され、この宛先を構成する送信先としてuserA、userB、userC、userDの４人の参加者に対応した４つのメールアドレス（sample-userA@sample.com、sample-userB@sample.com、sample-userC@sample.com、sample-userD@sample.com）が登録されている。

したがって、userA、userB、userC、userDの各クライアントユーザのいずれかが、クライアント１０のメーラによって宛先を同報通信宛先（sample-me@sample.com）にすると、メールの内容がメールサーバ２０に送られ、メールサーバ２０から同報通信宛先を構成する４人の参加者の４つのメールアドレスにメールの内容を複製して送るようになる。つまり、いずれかの参加者がメールの宛先として同報通信宛先を指定することで、この同報通信宛先を構成する全ての登録者に同時にメールを送信することができる。

ここで、本実施形態のクライアント１０側で実行される同報通信プログラムは、クライアント１０側で実行されるメーラとして実現されている。本実施形態の同報通信プログラムに係るメーラでは、あるユーザが同報通信を行う際、同報通信宛先の中から特定の登録者を除外して、それ以外の登録者に情報を送信したい場合に有効となる。

例えば、userAがメーリングリストsample-ml@sample.com宛にメールを送信しようとしている場合、特別な理由でuserDにはメールを送信したくないことも生じる。このような場合に本実施形態のメーラでは、メーリングリストsample-ml@sample.comを宛先に指定しながらも、除外したい登録者も設定することができる。

（クライアント側での処理の流れ）
先ず、userAは、メーラの宛先ヘッダ（Toヘッダ）にメーリングリストsample-ml@sample.comを入力する。また、本実施形態の同報通信プログラムであるメーラには拡張ヘッダとしてX-Excludeヘッダが用意されており、このX-Excludeヘッダに除外したいuserDのメールアドレスsample-userD@sample.comを指定することができる。そして、メール本文を含めてMessageAをメールサーバ２０に送信する。

クライアント１０のメーラは、メール送信処理の指示を受けるとMessageAをネットワーク経由でメールサーバ２０に送信する。この際、ヘッダには宛先ヘッダとしてメーリングリストsample-ml@sample.comが、また拡張ヘッダとしてX-Excludeヘッダに除外したいuserDのメールアドレスsample-userD@sample.comが格納されている。userAは、通常の同報通信と同様に、メーラによって宛先にメーリングリストを指定するとともに、その通信だけ除外した登録者がある場合には拡張ヘッダに除外したい登録者のメールアドレスを指定する。除外したい登録者が複数ある場合には、拡張ヘッダに複数のメールアドレスを並べて指定すればよい。

（メールサーバ側での処理の流れ）
メールサーバ２０は、userAから届いたメッセージ（MessageA）の中から、ToヘッダおよびX-Excludeヘッダの値を取得し、Toヘッダに含まれたメーリングリストの参加者リストから、X-Excludeヘッダに含まれた参加者を除いた形で、メッセージを複製し配布する。これにより、メーリングリストsample-ml@sample.comの登録者のうちuserA,userB,userCにはそれぞれMessageAが届き、メーリングリストsample-ml@sample.comの登録者ではあるがX-Excludeヘッダによって除外されたuserDにはMessageAが届かないことになる。

（メールメッセージのヘッダ拡張）
上記のように、クライアント１０のメーラによってメーリングリストから除外した登録者を指定するには、メールメッセージのヘッダ部において、下記のように拡張ヘッダを定義し追加する。なお、ヘッダ名に関しては特に規定しないが、ここでは例えば、X-Excludeとする。
(
x-exclude = "X-Exclude:" address-list CRLF
*address-listはInternet Message Format(RFC2822)準拠
)

図２は、メーラにおけるメールユーザエージェントの画面表示例を示す図である。このメールユーザエージェントでは、ヘッダ部とメール本文とが表示され、ヘッダ部には通常の宛先ヘッダであるToヘッダ、Ccヘッダ、Subjectヘッダの他に、除外したメールアドレスを指定する拡張ヘッダX-Excludeが用意されている。ユーザは、このメールユーザエージェントを利用して、その通信だけ送信を除外した登録者がある場合には、X-Excludeヘッダにその登録者のメールアドレスを入力すればよい。これにより、通常のメーリングリストとほぼ同じ簡単な手順によって一部の登録者を除外した同報通信を行うことができる。

（メールメッセージの配布）
メールサーバは、処理を単純化するため、メーリングリストの処理に関しては、メッセージ配布の待ち行列の最適化、アクセス制御、フィルタリング、再送などの高度な処理を除いて、単純に到着メッセージを複数のメッセージに複製し、メーリングリストに登録されている受信者リストに再配布するだけで完了することにする。

メーリングリストを有するメールサーバでは、メッセージを再配布する際に、以下の処理を行う。
（ａ）メッセージヘッダのX-Excludeフィールドの値を取得する。
（ｂ）Toヘッダ、Ccヘッダ、Bccヘッダに含まれたメーリングリストに対して、メーリングリストの登録アドレスから、X-Excludeヘッダに含まれたアドレスを取り除いてメッセージを複製し再配布する。ただし、メーリングリストの登録アドレスに、X-Excludeヘッダに含まれたアドレスがない場合、特に処理する必要はない。
（ｃ）メッセージの転送ルート上、To,Cc,Bccヘッダに含まれたメーリングリスト（メーリングリストの中にさらにメーリングリストがあるという階層構造を有するメーリングリストの場合は、下位のメーリングリストも含めて）、これらのメーリングリストを有するすべてのメールサーバが上記（ａ）、（ｂ）、（ｃ）のステップに従い処理を行う必要がある。

図３は、メールサーバ側のメーリングリスト処理プログラム（本実施形態のサーバ側の同報通信プログラム）の流れを説明するフローチャートである。先ず、メールを受信すると（ステップＳ１）、メールヘッダの情報を読み取り（ステップＳ２）、読み取ったメールヘッダの中に拡張ヘッダ（X-Excludeヘッダ）があるか否かを判断する（ステップＳ３）。

ここで、メールのヘッダ部の中に拡張ヘッダ（X-Excludeヘッダ）がない場合には通常のメーリングリスト処理として全ての登録者分のメールの複製と再配布を実行する（ステップＳ４）。一方、メールのヘッダ部の中に拡張ヘッダ（X-Excludeヘッダ）がある場合には、拡張ヘッダ（X-Excludeヘッダ）に記載された除外したいメールアドレスを取得する（ステップＳ５）。

そして、X-Excludeヘッダから取得したメールアドレスが宛先ヘッダの中にあるメーリングリストのメンバー（登録者）であるか否かを判断し（ステップＳ６）、メンバーでない場合は通常のメーリングリスト処理を行う（ステップＳ４）。

一方、X-Excludeヘッダから取得したメールアドレスがメーリングリストのメンバーである場合には、メーリングリストを構成するメールアドレスの中からX-Excludeヘッダのメールアドレスを取り除き、それ以外のメンバーに対してメールの複製と再配布を実行する（ステップＳ７）。これにより、X-Excludeヘッダでメーリングリストのメンバーのうちいずれかのメールアドレスが指定されている場合、そのメールアドレスを除外した残りのメールアドレスに対してのみメールを送信することが可能となる。

（X-Excludeヘッダの扱い）
拡張ヘッダであるX-Excludeヘッダは、最終的受信者にメッセージが届くまで、途中のメールサーバでの処理等によって変更しないようにする。ただし、Bccヘッダのみ対象メーリングリストが指定されている場合は、X-ExcludeヘッダはBccヘッダと同等の扱いになる。

（メールユーザエージェントにおけるX-Excludeヘッダ）
先に説明したように、送信側クライアントのユーザエージェントは、ユーザにX-Excludeヘッダを提示し、除外したいメールアドレスを入力できるようにする必要がある（図２参照）。一方で、受信側クライアントにとっては、受信したメールに対して返信することもあるので、受信したメールは、メーリングリストの全員に送信されたものなのか、それとも特定の参加者を除外して送信されたものなのかを知る必要がある。

そこで、受信側のユーザエージェントは、受信したメッセージの中のX-Excludeヘッダとその値とを反映できるものとする。図４は、同報通信を受信したクライアントでのメールユーザエージェントの画面表示例を示す図である。同報通信を受信したクライアントのメールユーザエージェントでは、ヘッダとして送信元であるFromヘッダ、送信日時であるDateヘッダ、宛先であるToヘッダおよびCcヘッダ、Subjectヘッダとともに、拡張ヘッダであるX-Excludeヘッダが用意されている。送信者がX-Excludeヘッダを利用して除外するメールアドレスを指定した場合には、受信者側でもその情報が反映され、受信側メールユーザエージェントのX-Excludeヘッダにその除外したメールアドレスが反映される。これにより、メール受信者はそのメールが同報通信であっても一部の登録者には送られていないことを把握することができる。

また、この受信側のメールユーザエージェントから返信を行う場合には、図２に示すように拡張ヘッダであるX-Excludeヘッダが表示され、ここには送信元から指定された除外したいメールアドレスが反映されることになる。もし、X-Excludeヘッダに除外したいメールアドレスが反映されないと、誤って全ての登録者に返信されてしまい、当初除外した登録者にも返信が送られてしまうことになる。したがって、同報通信メールを受け取ったユーザが返信を行う場合には必ずX-Excludeヘッダに送信元が指定した除外したいメールアドレスを反映させるようにする。これにより、返信を行う際に誤って除外した登録者に送られてしまうことを防止できる。

このように、本実施形態では、メーリングリストを利用した際、メールのヘッダを拡張してToヘッダやCcヘッダに宛先メールアドレスを追加するのと同じ操作で、拡張ヘッダに送信したくないメーリングリストの参加者のメールアドレスを追加するだけの簡単な操作によって、特定の参加者に送信しないようにする同報通信を容易に実現することが可能となる。

具体的な利用例としては、例えば、企業内など業務上でよく使われているメーリングリストの場合、通常ではメーリングリストの参加者全員にメールを送信することになるが、特に冠婚葬祭関係では、当事者本人となる特定メンバーには送信したくない場合もある。この際、本実施形態で示した手法を利用して、メーリングリストを指定するとともに、送信したくない特定メンバーのメールアドレスを拡張ヘッダに追加するといった簡単な操作で、特定メンバーを除外したメーリングリストを行うことが可能となる。

（ＩＰ電話アプリケーションへの適応）
上記の実施形態では、主としてメーリングリストによる電子メール送信の場合を例としてが、本発明では、同様な技術によってＩＰ電話アプリケーションへの適用も可能である。

すなわち、近年、ＳＩＰ（Session Initiation Protocol）やＨ．３２３プロトコルによりＩＰ電話網の構築が盛んになってきている。ＩＰ電話の分野でも、代表電話に電話をかけると登録された参加者全員に電話がかかるような同報通信アプリケーションがある。そこで、こういった代表電話によるコーリングリストのような仕組みにも、本発明と同様の手法で、ヘッダ等の拡張により、特定の相手を除外して、それ以外の参加者のみに電話をかけるようにすることが可能となる。

本実施形態に係る同報通信プログラムの実現方法を説明する模式図である。 メーラにおけるメールユーザエージェントの画面表示例を示す図である。 メールサーバ側の処理プログラムの流れを説明するフローチャートである。 同報通信を受信したクライアントでのメールユーザエージェントの画面表示例を示す図である。

符号の説明

１０…クライアント、２０…メールサーバ

Claims (6)

1. 同報通信を行うサーバに対してネットワークを介して情報送信を行うクライアントで実行される同報通信プログラムにおいて、
   複数の送信先のリストとなる同報送信宛先を受け付けるステップと、
   前記同報送信宛先の複数の送信先の中から除外する送信先を受け付けるステップと、
   受け付けた前記同報通信宛先と前記除外する送信先とをヘッダに格納して送信対象の情報とともに前記サーバに送信するステップと
   を備えることを特徴とする同報通信プログラム。
2. クライアントから送られた同報通信の情報を受け付けて所定の送信宛先に当該情報を送信するサーバで実行される同報通信プログラムにおいて、
   前記クライアントから送られた同報通信の情報の中からヘッダを読み取り、同報通信宛先の複数の送信先の中から除外する送信先があるか否かを判断するステップと、
   前記除外する送信先がない場合には前記同報通信宛先の複数の送信先の全てに前記クライアントから送られた情報を送信し、前記除外する送信先がある場合には前記同報通信宛先の複数の送信先の中の前記除外する送信先以外の送信先に前記クライアントから送られた情報を送信するステップと
   を備えることを特徴とする同報通信プログラム。
3. 請求項１記載の同報通信プログラムにおいて、
   前記サーバから送信された情報について返信を行うにあたり、前記情報のヘッダに前記除外する送信先が格納されているか否かを判断し、格納されている場合には前記返信の宛先として前記同報通信宛先とともに前記除外する送信先を反映させる
   ことを特徴とする同報通信プログラム。
4. 請求項１記載の同報通信プログラムにおいて、
   前記除外する送信先は拡張ヘッダに格納する
   ことを特徴とする同報通信プログラム。
5. 請求項２記載の同報通信プログラムにおいて、
   前記クライアントから送られた同報通信の中のヘッダに前記除外する送信先が格納されている場合、前記除外する送信先以外の送信先に情報を送信する際のヘッダに前記除外する送信先を格納する
   ことを特徴とする同報通信プログラム。
6. 請求項５記載の同報通信プログラムにおいて、
   前記除外する送信先は拡張ヘッダに格納する
   ことを特徴とする同報通信プログラム。
   

Images