(57)【要約】【課題】  本発明は、複数の宛先にメールを送る際に、宛先の指定誤りを警告し、誤送信を防ぐ、すなわちアドレス情報の漏洩を防ぐことを課題とする。【解決手段】  前記課題は、ネットワーク１１０を介して接続された端末１００からユーザインタフェース１０１を介して指定した宛先に複数ドメインが含まれていないかどうかを宛先判定部１０２が判定し、含まれている場合は警告メッセージを表示した後に、メールサーバ１２０に送信することによって達成される。【選択図】  図１
2006343900.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数の端末からメールの送受信が可能なメールシステムであって、  TO及びCCに指定された宛先に異なるドメイン部を持つ複数のアドレスが存在する場合に警告することを特徴としたメールシステム。
【請求項２】
請求項１に記載のメールシステムであって、予め社内ドメインを登録する社内ドメイン管理機能と、TO及びCCに指定された宛先のうち、前記社内ドメイン管理機能に登録された社内ドメインを除いた宛先を対象として、異なるドメイン部を持つ複数のアドレスが存在する場合に、アドレスが複数である旨を警告することを特徴としたメールシステム。
【請求項３】
請求項１に記載のメールシステムであって、メールに指定された機密性を表す属性を重要度として取得し、重要度ごとに予めドメインを登録するドメイン管理機能と、TO及びCCに指定された宛先のうち、前記重要度ごとのドメイン管理機能に登録されたドメインを除いた宛先を対象として、異なるドメイン部を持つ複数のアドレスが存在する場合に、アドレスが複数である旨を警告することを特徴としたメールシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された複数の端末からメールの送受信が可能なメールシステムに関する。
【背景技術】
【０００２】
特許文献１には、メールの送信先アドレスを記憶する手段を備え、ドメイン部を比較することにより、これまで送付したことのないドメイン部を含むアドレスへメール送信しようとした時に通知するメールシステムが示されている。
【０００３】
【特許文献１】特開２００２−３２４０２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上記従来技術によれば、宛先の誤りに気づきやすくなるものの、宛先情報そのものを他人に漏洩させてしまうという課題がある。
【０００５】
一般的なメールシステムでは、宛先の種別にはTO、CC、BCCの３種類があり、TOやCCに宛先Aと宛先Bを指定した場合、Aに送信されていることはBに伝わり、逆にBに送信されていることはAにも伝わるようになっている。また、BCCに指定した宛先は他の誰にも通知されない。このことを利用して、誰に送ったかを他の同報者に伝えないようにすることが可能である。
【０００６】
しかし、宛先指定の際、BCCとすべきところを誤ってTOやCCを指定してしまった時に気づきにくいため、宛先そのものに問題がなくても、宛先の情報が他人に漏洩しやすいという課題があった。
【０００７】
本発明は、この課題に鑑みてなされたもので、宛先の指定誤りを警告し、誤送信を防ぐことを目的とする。
【課題を解決するための手段】
【０００８】
本発明では、上記の課題を解決するために、TO及びCCに指定された宛先に異なるドメイン部を持つ複数のアドレスが存在する場合に警告する機能を備える。
【発明の効果】
【０００９】
本発明は、以上の機能を備えるため、宛先の指定誤りを警告し、誤送信を防ぐことが可能となる。
【発明を実施するための最良の形態】
【００１０】
以下、最良の実施形態を添付図面を参照しながら説明する。
【００１１】
図１は、本発明の第１の実施形態にかかるメールシステムの全体構成を説明する図である。図において、１００はこのシステムの利用者が操作する端末、１２０はメールシステムを提供するメールサーバ、１１０は端末１００とメールサーバ１２０を接続するネットワークである。端末１００は、メール送信操作に関わる機能を提供するもので、ユーザインタフェース１０１、宛先判定部１０２、通信部１０３を有し、通信部１０３を介して、メールサーバ１２０と通信する。メールサーバ１２０は、メール送信に関わる機能を提供するもので、通信部１２１、メール配信機能１２２を有する。
【００１２】
端末１００のユーザインタフェース１０１を利用者が操作すると、操作に応じて通信部１０３、ネットワーク１１０を介して、メールサーバ１２０の通信部１２１に伝えられ、メール配信機能１２２によってメールが配信される。メール配信機能１２２は、一般的なイントラネットやインターネットに接続され、他のメールサーバとネットワークを介して接続されているものとする。
【００１３】
図２は、宛先判定部１０３の処理フローである。まず、ステップ２０２でTO及びCCに指定された宛先のドメイン部を抽出する。ドメイン部とは、例えばメールアドレスがaaa@aaa.comであった場合、@以降のaaa.comの部分である。インターネットにおいて、このドメイン部は会社や学校を示すことが多い。
【００１４】
次にステップ２０３でドメイン部が２種類以上あるかを調べる。１以下の場合はステップ２０６に進み、メール送信処理を行う。
【００１５】
ステップ２０３でドメイン部が２種類以上であった場合は、ステップ２０４に進み、メッセージを表示する。例えば、「ドメインが複数含まれます。このまま送信してもよいですか？」などのメッセージを表示し、これから送信しようとしているメールの宛先に複数のドメインが含まれることを示し、利用者に送信していいかどうかの判断結果をボタンなどにより示してもらう。ここでは、画面上に「はい」及び「いいえ」のボタンを配置したものとし、その結果をステップ２０５で判定する「はい」の場合ステップ２０６に進みメールを送信する。「いいえ」の場合、メール送信処理を行わず終了する。
【００１６】
図３はステップ２０４で表示するメッセージの例である。メッセージ３１０は、メッセージ部３１１とボタン３１２、ボタン３１３で構成される。メッセージ３２０は、メッセージ部３２１とボタン３２２、ボタン３２３で構成される。メッセージ３２０は、メッセージ３１０により詳細な情報を加えたものである。このように、宛先の具体的な内容を沿えたメッセージを表示してもよい。
【００１７】
例えば、TOに指定された宛先が、aaa@aaa.com、bbb@bbb.com、ccc@bbb.com、ddd@ccc.comの４つであった場合、含まれるドメインは、aaa.com、bbb.com、ccc.comの３つである。この場合、ステップ２０４でメッセージを表示し、利用者の判断に従う。
【００１８】
このようにすることで、TO及びCCに複数のドメインが含まれている場合に利用者の注意を喚起することが出来、アドレス情報の漏洩を防ぐことが可能となる。
【００１９】
次に第２の実施形態について図面を用いて説明する。図４は、第２の実施形態を表す全体像である。端末１００は、宛先判定部４０１、社内ドメイン記憶テーブル４０２を備える。その他、図４のうち図１と同一部分については、図１と同一の符号を付した。
【００２０】
社内ドメイン記憶テーブル４０２の詳細を図５に示す。社内ドメイン記憶テーブル４０２は、番号５０１と、社内ドメイン５０２で構成される。
【００２１】
図６は、宛先比較判定部４０１の処理フローを示す。利用者がユーザインタフェース部を介してメール送信する際に、宛先判定部４０１が図６のフローに従って処理を行う。まず、ステップ６０２で宛先に指定されたドメイン部を抽出する。次に、ステップ６０３で含まれるドメインのうち社内を除く数が２以上かどうかを判定する。社内かどうかは、社内ドメイン記憶テーブル４０２を参照し、比較することにより行う。１つ以下の場合は、ステップ６０７に進み、メールを送信する。
【００２２】
ステップ６０２でメールが２つ以上の場合は、ステップ６０４に進み、メッセージを表示する。ここで利用者が「はい」のボタンを押すとステップ６０６に進み、メールを送信する。また、「いいえ」のボタンを押すとメールを送信せずに終了する。
【００２３】
図７はステップ６０４で表示するメッセージの例である。メッセージ７１０は、メッセージ部７１１、ボタン７１２、ボタン７１３で構成される。また、メッセージ７２０は、メッセージ部７２１、ボタン７２２、ボタン７２３で構成される。
【００２４】
例えば、TOに指定された宛先が、aaa@aaa.com、bbb@bbb.com、ccc@ccc.comの３つであった場合、このうち、aaa.comは社内ドメイン管理テーブル４０３に含まれるため、これを除いたドメインは、bbb.com、ccc.comの２つである。この場合、ステップ６０４でメッセージを表示し、利用者の判断に従う。
【００２５】
上記の実施例においては、宛先に含まれるドメインが２つ以上の時に警告するようにした他、３つ以上や４つ以上のように変えてもよい。また、いくつ以上で警告するかを設定で変更できるようにしてもよい。
【００２６】
図８、図９に本発明を実施するメールシステムの別の態様を示す。ドメイン記憶テーブル８０１には、図５で説明した番号５０１、社内ドメイン５０２に加えて、「重要度」カラムを追加している。社内ドメインは、社内だけに限らないという意味で、単に、ドメインとした。メールの宛先指定８０４は、一般のメールシステムによるメールの宛先指定画面である。主題、宛先、本文からなり、さらに、メール内容の重要度を属性として持つ。重要度は、親展メールなどの機密性を持つものや、メール本文の機密性によって指定できる属性である。たとえば、ドメイン記憶テーブル８０２は、機密性の高いグループとし、重要度に「Ａ」を、ドメイン記憶テーブル８０３は、ドメイン記憶テーブル８０２に設定したグループよりは機密性が低いグループとし、重要度に「Ｂ」を設定している。図９の処理フローに従い、宛先判定部４０１は、メールの宛先指定８０４により、宛先と重要度の指定を受けると、ドメイン部と重要度を抽出する（ステップ９０１、９０２）。重要度に従って、ドメイン記憶テーブルを参照する（ステップ９０３）。メールの宛先指定８０４では、重要度に「Ａ」が指定されているので、ドメイン記憶テーブル８０２とドメイン記憶テーブル８０３を参照し、ドメインを比較する。仮に、重要度に「Ｂ」が指定された場合は、ドメイン記憶テーブル８０３のみを参照し、ドメインを比較する（ステップ９０４）。このように、指定された重要度によって、参照するドメイン記憶テーブルと、比較対照のドメインを選択することで、機密性を表す重要度にしたがったドメイン比較を可能とする。ここでは、ドメイン記憶テーブルの数や重要度の種類を限定するものではない。その後、ステップ９０５905、９０６を経てステップ９０７を実行する。図９で追加したステップ９０２は、重要度であったが、他にも、添付ファイルの有無やＢＣＣ宛先の有無、返信メールか否かなどを条件とし、参照するドメイン記憶テーブルと、比較対照のドメインを選択する構成としても良い。
【００２７】
上記の実施例においては、宛先判定部１０２や、宛先判定部４０１、社内ドメイン記憶テーブル４０２を端末内に配置したが、メールサーバ上や別のサーバ上に配置しても構わない。
【００２８】
上記の実施例においては、端末をひとつだけとしたが、複数の端末がメールサーバに接続されるようにしてもよい。また、メールサーバを複数配置し、連動して動作するシステムとしてもよい。
【００２９】
以上説明したように本発明の各実施形態によれば、TO及びCCに複数のドメインが含まれている場合に利用者の注意を喚起することが出来、アドレス情報の漏洩を防ぐことが可能となる。
【図面の簡単な説明】
【００３０】
【図１】本発明の第１の実施形態にかかるメールシステムの全体構成を説明する図。
【図２】宛先判定部１０２の処理フロー。
【図３】ステップ２０４で表示するメッセージの例。
【図４】第２の実施形態を表す全体像。
【図５】社内ドメイン記憶テーブル４０２の詳細。
【図６】宛先判定部４０１の処理フロー。
【図７】ステップ６０４で表示するメッセージの例。
【図８】ドメイン記憶テーブル８０１の詳細。
【図９】重要度ごとの宛先判定部の処理フローの例。
【符号の説明】
【００３１】
１００…利用者が操作する端末、１１０…ネットワーク、１２０…メールサーバ、１０１…ユーザインタフェース、１０２…宛先判定部、１０３…通信部、１２０…メールサーバ、１２１…通信部、１２２…メール配信機能。
【図１】
2006343900.tif 000003
【図２】
2006343900.tif 000004
【図３】
2006343900.tif 000005
【図４】
2006343900.tif 000006
【図５】
2006343900.tif 000007
【図６】
2006343900.tif 000008
【図７】
2006343900.tif 000009
【図８】
2006343900.tif 000010
【図９】
2006343900.tif 000011