電子メール送信制御プログラム、電子メール送信制御方法、コンピュータ装置

【課題】多数の宛先に同報で送信される電子メールについて誤送信を防止する電子メール送信制御プログラムを提供する。
【解決手段】本発明にかかる電子メール送信制御プログラムは、まず、コンピュータ装置１の外部に送出される電子メールを横取りする。次に、その電子メールに含まれる宛先メールアドレスの総宛先数と、その宛先メールアドレスに含まれる外部メールアドレスの混入数を取得する。そして、総宛先数が所定以上で、かつ、混入数が所定の閾値以下であるかどうかを判定し、この２つの条件を満足する場合に電子メールの送信を中断してユーザに対して警告を行う。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メール送受信用プログラムによって送信される電子メールの送信を制御するための電子メール送信制御プログラムに関する。
【背景技術】
【０００２】
近年、あらゆる分野における事業活動において電子メールの活用は必要不可欠となっており、１日に１００通を超える電子メールをやり取りすることが常態化している。
電子メールは手軽で瞬時に送受信が可能であるという利点がある一方で、誤った内容で送信してしまったり、宛先を間違えたりするケースも多い。
【０００３】
こういったいわゆる電子メールの誤送信を未然に防ぐ方法は複数提案されている。その中には、特許文献１のように、送信先のメールアドレスが社内の者か社外の者かをメールアドレスのドメイン名に基づいて自動的に判断するものがあり、社外であれば送信を拒否したり、本当に送信するかどうかの警告を与えたりする方法がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−４４４０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記のように、社外のメールアドレスに対する電子メールの送信を画一的に拒否したり、警告を与えたりする方法は、例えば、業務上社外の取引先等と電子メールをやり取りすることがほとんどない社員や、許可なく社外との電子メールのやり取りをすることができない社員については有効であるが、社外の者との電子メールのやり取りが頻繁な社員にとっては電子メールの送信を実行する度に余計な手間がかかり都合が悪い。
例えば、社外の者に電子メールを送信しようとする場合に、警告画面を表示して本当に送信するかどうかを入力するように促すとすると、１日に１００通を超えるような数の電子メールを送る者にとっては非常に煩わしく、頻繁に警告画面が出ると、無意識に送信する旨の入力をする習慣がついてしまい警告の実効性が低下する、といったことが起こりうる。
【０００６】
このような問題に対処するため、社外には送信したくない内容を含む電子メールかどうかを電子メールの本文を見て判定し、内容に応じて警告を行う方法も種々提案されている。例えば、特定の「秘密」等の文字が含まれている場合や、暗号化されていない添付ファイルが存在する場合に警告をする、といったものがある。
しかし、電子メールの内容から自動的に社外に送っても良いかどうかを精度よく判定する方法を実現するには、インテリジェントな内容解析が可能なソフトウェアを導入しなければならないので、システムの導入に高いコストがかかるという問題がある。
また、たとえインテリジェントなソフトウェアを導入したとしても、業務内容によっては、内容解析ソフトウェアの処理に馴染まず、不要な警告が頻繁に行われたり、本来は警告すべきときに警告が行われない、といったこともありうる。
【０００７】
電子メール送信ソフトのユーザにとっては、過剰な警告や高度で複雑なロジックに基づく警告よりも、注意散漫で誤送信をしてしまうかもしれないケースでのみ警告が出るような簡便な仕組みの方がむしろありがたいことが多い。
本発明は、上記のような点に鑑みてなされたものであり、誤送信をしてしまう可能性が高いと思われるケースを抽出し、そういったケースに合致した場合にユーザに警告を発することができる電子メール送信制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明にかかる電子メール送信制御プログラムは、
コンピュータ装置外部に送出されようとする電子メールを検出する検出ステップと、
前記電子メールの送信先メールアドレスが以下の条件（１）及び（２ａ）に合致するかどうか又は条件（１）及び（２ｂ）に合致するかどうかを判定する判定ステップと、
前記判定の結果、条件に合致していれば、電子メールの送信処理を中断してユーザに警告を行う警告ステップと
を前記コンピュータ装置に実行させるためのプログラムである（請求項１）。
（１）検出された電子メールの送信先メールアドレスの総数である総宛先数が所定数以上である。
（２ａ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記総宛先数又は所定数に占める割合が所定割合以下である。
（２ｂ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記所定数よりも小さい閾値以下である。
【０００９】
本発明にかかる電子メール送信制御プログラムを用いれば、多数の宛先に同報で送信しようとする電子メールの送信先メールアドレスの大半が同じ事業体（例えば親会社とその子会社を含む範囲等）に属し、その中に僅かな数だけ、当該事業体以外に属する外部メールアドレスが含まれているといったケースのように、ユーザが間違いに気が付き難いケースでユーザに対して送信しても良いかどうかの警告を行うことが可能となる。
【００１０】
電子メールを受信した相手がその電子メールに返信する際には、宛先の電子メールアドレスのチェックを怠る傾向がある。特に、大勢の宛先に同報の電子メールが送信された場合には要注意である。
こういった大勢の宛先に同報された電子メールについては、受信した複数人が当該電子メールに対して返信を繰り返し、大勢での議論が行われるケースも少なくないが、宛先の大半が同じ事業体に属するような場合には、同じ事業体に属するメンバーが連続して返信してくることが多い。そういったやりとりを見たメンバーは、当該やりとりが同じ事業体のメンバー内でのみ行われているものと勘違いして、同じ事業体のメンバーのみに共有されるべき機密情報等に関する発言を記載した電子メールを返信してしまうといったミスが起こりうる。
【００１１】
本発明によれば、このようなケースで送信前にメンバーに警告をすることが可能となるので、機密情報等の当該事業体外への漏洩を未然に防ぐことが可能になる。また、従来のように、外部メールアドレスが含まれていれば画一的に警告をするといった方法に比べて警告対象数が少なくなるので、頻繁な警告によるユーザの負担増や警告の実効性の低下といった問題点も解消される。
送信先メールアドレスの総宛先数と外部メールアドレスの混入数の具体的な数は、例えば、前記総宛先数が１０個以上で前記混入数が２個以下（総宛先数に占める割合が２割以下）といったように、総宛先数に比べて混入数が僅かで、ユーザが瞬時には確認しにくく見落としやすいケースで適用すると好適である。
【００１２】
なお、同じ事業体に属するかどうかは、電子メールアドレスのドメイン名が送信元の電子メールアドレスと同一であるかどうか、で確認することができる。ただし、同じ事業体に属していても、例えば部署等によって異なるドメイン名を使用している場合もあるから、事前に同一の事業体に属するドメイン名を複数記憶しておき、当該記憶されたドメイン名と一致するかどうかによって同一の事業体のメールアドレスかどうかを判断するようにしても良い。
【００１３】
前記判定ステップは、前記条件（２ｂ）の閾値を前記総宛先数又は所定数毎に設定した判定テーブルを記憶する記憶ステップを備え、前記混入数と当該判定テーブルの閾値との比較によって前記条件（２ｂ）に合致するかどうかを判定するようにしても良い（請求項２）。
このような判定テーブルを用いることで、警告を行う条件をきめ細かくすることが可能になる。例えば、総宛先数が４個以下なら前記閾値をゼロとし、５個以上９個以下なら前記閾値を１とし、１０個以上１５個以下なら前記閾値を２とし、１６個以上なら前記閾値を３とするといったように設定し（例えば図１０等）、前記閾値と比較して混入数が閾値を下回っているかどうかで警告をするかどうか判断する、といった方法を用いることができる。
【００１４】
なお、この場合、前記検出ステップでは、ユーザが受信した電子メールに対する返信の電子メールのみを検出するようにしても良い（請求項３）。
前述のようなミスは、最初に１つずつ宛先メールアドレスを設定してから送信する初回の電子メールの送信では起こりにくいが、返信するケースでは発生しやすいため、返信するケースに限って警告を実行することで、ユーザに対する警告の頻度を減らし、余計な手間を発生しにくくすることが可能になる。
なお、返信の電子メールであるかどうかは、例えば電子メールのタイトルの先頭に「Ｒｅ：」の文字が含まれるかどうかで判断しても良いし、ヘッダの領域に「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ」や「Ｒｅｆｅｒｅｎｃｅｓ」等が記載されていれば返信であると判断するようにしても良い。
【００１５】
なお、前記条件（１）の所定数は、単位期間当たりに送信される電子メールの総数が大きいほど小さい数に設定されると良い（請求項４）。
電子メールの送信数が多いユーザほど、１通の電子メールの作成や宛先の確認に要する時間が短いため、注意散漫になりがちでミスが起きやすい。従って、多数の電子メールを送るユーザほど、送信先メールアドレスの総数が少ないケースであっても警告を与えることが望ましい。この場合の単位期間当たりに送信される電子メールの総数とは、例えば１日や１週間当たりの電子メールの送信数等を指し、例えば、１日に１００通を超える場合には前記所定数を１０個とするが（所定数が９個以下の場合を警告対象外とする）、１日に２００通を超える場合には前記所定数を８個とする（所定数が７個以下の場合を警告対象外とする）、といった方法で設定すると良い。
なお、単位期間当たりの電子メールの送信数は、前記コンピュータ装置から電子メールが送出される度にインクリメントされるカウンタ等を用いることで計数することができ、同一のコンピュータ装置を使用して複数のユーザが電子メールを送信するような場合には、送信元のメールアドレス毎にカウンタを持たせるようにすれば良い。
【００１６】
また、前記条件（２ｂ）の閾値を１としても良い（請求項５）。
つまり、外部メールアドレスが１つだけ紛れ込んでいるケースのみを警告の対象とするということである。混入数が複数の場合に比べて発見し難いため、このような最も見落としの生じやすいケースに限定することで、警告の頻発によるユーザのストレスを軽減することが可能になる。
【００１７】
なお、前記警告ステップは、ユーザに対して前記判定の結果に応じた表示を行う表示ステップと、ユーザの操作を受け付ける操作受付ステップと、前記操作受付ステップでユーザから受け付けた操作結果に応じて前記電子メールを送信するか否かを決定する決定ステップとを備えることが望ましい（請求項６）。
判定結果に応じた表示とは、例えば、警告の原因となった外部メールアドレスを表示して確認を促す文字列等をコンピュータ装置のディスプレイ等に表示すること等を指す。
また、ユーザから受け付ける操作とは、電子メールをそのまま送信するか、何らかの修正を加えてから送信するかといったユーザの意思表示に関する操作であり、例えば、表示画面上に「そのまま送信」と「中断」の２つのボタンを表示させて、いずれかを押下させる操作等を指す。
このように、ユーザに対して警告内容や次のアクションの選択肢等を分かりやすく表示等することで、ユーザの作業を支援することができる。
【００１８】
前記決定ステップで前記電子メールを送信することに決定した場合、前記操作受付ステップでユーザから受け付けた操作結果に応じて、前記電子メールの送信先に含まれる外部メールアドレスの全部又は一部を削除する宛先編集を行う削除ステップと、前記宛先編集後の電子メールを送信する宛先編集後送信ステップとを前記コンピュータ装置に実行させるようにするとさらに良い（請求項７）。
ユーザが警告の対象となった電子メールをそのまま送信するべきではない、と判断した場合に行う操作は主に３パタン想定される。そもそも電子メールの送信自体をやめるか、メール本文の内容を再編集してから送信するか、外部メールアドレスを削除して同じ事業体に属するメンバーにのみ送信することにするか、のいずれかである。
このうち、外部メールアドレスを削除して同じ事業体に属するメンバーにのみ送信する場合、本発明のように自動的に外部メールアドレスを削除すれば、わざわざユーザに作業させるよりも効率が良く好適である。
【００１９】
このような外部メールを削除してからの送信をユーザに選択させるには、例えば、前記操作受付ステップにおいて、表示画面上に「そのまま送信」と「中断」の２つのボタンに加えて「外部メールアドレスを削除してから送信」という趣旨の３つ目のボタンを表示させてそのボタンを押下させるようにすれば良い。
なお、ユーザからの指示によって自動的に全ての外部メールアドレスを削除するのではなく、外部メールアドレスを一覧で表示すると共に、削除する対象（又は削除しない対象）を選択するチェックボックスを表示してユーザに削除する外部メールアドレスを選定させるようにしても良い。
【００２０】
なお、この電子メール送信制御プログラムを用いてコンピュータ装置から送出されようとする電子メールの送信を制御する方法やコンピュータ装置自体も大変有用である（請求項８、請求項９）。
【発明の効果】
【００２１】
以上のように、本発明によれば、ユーザが見落としやすい電子メールの宛先の間違いを検出して、電子メールの誤送信を未然に防止することが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本発明に係るコンピュータ装置のハードウェア構成の概要を示す模式図である。
【図２】本発明に係るコンピュータ装置に搭載されたプログラムの関係を示す模式図である。
【図３】本発明の各プログラム等の動作シーケンスの概要を示す模式図である。
【図４】ＳＭＴＰの通信手順を示す模式図である。
【図５】本発明による電子メール送信制御方法において使用されるＩＰアドレスやポート番号の一例を示す図である。
【図６】本発明による電子メール送信制御方法において使用されるＩＰアドレスやポート番号の一例を示す図である。
【図７】ポリシー判定部Ｐが実施する外部メールアドレス混入防止ポリシーに基づく判定の処理フローの一例を示す図である。
【図８】内部ドメインテーブルの一例を示す図である。
【図９】電子メールの宛先のメールアドレスの一覧の一例を示す図である。
【図１０】判定テーブルの一例を示す図である。
【図１１】（ａ）及び（ｂ）はユーザに操作を促す通知画面の一例を示す図である。
【発明を実施するための形態】
【００２３】
（第１の実施形態）
以下、本発明の第１の実施形態を、図面を参照しながら詳細に説明する。
図１は、メールの作成と送信を行うコンピュータ装置１（クライアント）のハードウェア構成を示す模式図である。
【００２４】
〔構成の概要〕
ＣＰＵ１０１は、コンピュータ装置１の備える機能を実現するためのコンピュータプログラムをハードディスク１１２から読み出してメモリ１１１にコピーして実行する機能を備えている。
本発明で実行される前記コンピュータプログラムとしては、コンピュータ装置１のオペレーティングシステム（以下、ＯＳという。）のプログラム、電子メール送信プログラムＭ（以下、メーラという。）、及び電子メール送信制御プログラムが挙げられる。
この場合、前記電子メール送信制御プログラムは、ネットワークドライバ部Ｎ、プロキシーサーバ機能部Ｓ、及び、ポリシー判定部Ｐを含む構成となっている。
ＯＳや電子メール送信制御プログラムは、コンピュータ装置１の電源がオンされた時点で自動的にハードディスク１１２から読み出されてメモリ１１１にコピーされ、常時実行可能な状態となるが、電子メール送信プログラムは、通常ユーザがメールの作成や送受信を行うタイミングで随時ハードディスク１１２から読み出されてメモリ１１１にコピーされて実行される。
【００２５】
なお、ＯＳには、電子メールを送受信するために必要なＴＣＰ／ＩＰ通信を実行するためのＴＣＰ／ＩＰ通信ライブラリが含まれており、予め用意されたＡＰＩ関数を用いてＩＰデータパケットの送受信を行うことができるようになっている。このＡＰＩ関数は、前記ＴＣＰ／ＩＰ通信ライブラリとアプリケーションプログラムとの間のデータの受け渡しを行うために使用されるものである。
そして、このＴＣＰ／ＩＰ通信ライブラリによって、コンピュータ装置１から外部に送信すべきＩＰデータパケットを通信インタフェース１２１を介して他のコンピュータ装置（例えば電子メールサーバ２）に送信したり、他のコンピュータ装置からのＩＰデータパケットを通信インタフェース１２１を介して受信したりする機能が実現される。
【００２６】
なお、図１ではコンピュータ装置１のＣＰＵが１つだけの例を示しているが、複数のＣＰＵによって構成されていても良いし、実現すべき機能のうちの一部については、その機能を実行可能な専用チップ（ＩＣ等）を備えるハードウェア構成としても良い。
【００２７】
〔プログラムの動作〕
次に、図２と図３を用いて、本発明にかかる電子メール送信制御プログラムの動作を詳細に説明する。なお、使用されるＩＰアドレスやポート番号等に着目してそれらを図示したものが図５および図６になる。
実施形態に登場する各種プログラムはコンピュータ装置１に対する命令を組み合わせたものであるから、プログラムによって実現される動作や機能の主体はあくまでもコンピュータ装置１であるが、発明内容を把握しやすくするために、各種プログラムを動作の主体として記載する。
【００２８】
〔メーラＭの設定〕
ユーザが使用するメーラＭには電子メールの作成と送受信をする機能が備えられており、ユーザはメーラＭを使用して作成した電子メールを送信することができる。
通常、メーラＭは、使用する電子メールサーバのＩＰアドレスとポート番号を設定しなければ動作しない仕組みになっているので、メーラＭには電子メールサーバ２のＩＰアドレスとポート番号が設定されている。
本実施形態では、このコンピュータ装置１に電子メール送信制御プログラムがインストールされているかどうかに関係なく、メーラＭには常に電子メールサーバ２のＩＰアドレスＡ２とポート番号Ｎ２が設定されていれば良く、電子メール送信制御プログラムがインストールされている場合にもこの設定を変更する必要はない。
【００２９】
〔ＳＭＴＰの基本手順を用いた電子メールの送信処理の概要〕
コンピュータ装置１のＯＳに含まれるＴＣＰ／ＩＰ通信ライブラリ（以下、通信ライブラリという。）Ｔを使用するために用意されるＡＰＩ関数には、例えば、メーラＭによってメールの送信処理が実行される際に送信されるべきＩＰデータパケットの送信先やデータ内容等を引数としてコールされる送信関数や、特定のポート番号に対応付けて生成されるＴＣＰのソケット等の識別子を引数として当該ポート番号宛に送信されたＩＰデータパケットを受信するためにコールされる受信関数等がある。
メーラＭは、電子メールの送信処理を実行する場合、電子メールの送信先のメールアドレスやメール本文の文字列等を格納したテキストデータへのポインタや送信先のＩＰアドレス等を引数として送信関数をコールすることで、電子メールを送信することができる。
【００３０】
なお、電子メールの送受信を行う場合、通常ＳＭＴＰ（ＳｉｍｐｌｅＭａｉｌＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）というプロトコルを使用することが多い。このＳＭＴＰでは、電子メールサーバと電子メール送受信用のクライアント装置との間で所定の通信手順に従ってやりとりが行われる。この通信手順を、図４を用いて説明する。
なお、このＳＭＴＰの通信手順はＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）のＲＦＣ（ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔ）で標準仕様が定められており、以下はそのＲＦＣで定められた手順と同じである。
まず、電子メールサーバとクライアント装置との間でＴＣＰの通信コネクションが確立される。この場合、電子メールサーバのポート番号は通常２５番が使用される。そして、以降のやりとりは、このＴＣＰ通信コネクション上で、ＩＰデータパケット形式のデータを交換することで行われる。
【００３１】
ＴＣＰ通信コネクションが正常に確立されたら、まず、クライアント装置は、自身のドメイン名を格納したＥＨＬＯコマンドを送信する。電子メールサーバはこれに応じて応答信号を返信する。
クライアント装置は、ＥＨＬＯコマンドに対する応答信号を受けたら、電子メールの送信元メールアドレス（通常はユーザのメールアドレス）を格納したＭＡＩＬコマンドと宛先メールアドレスを格納したＲＣＰＴコマンドとをそれぞれ送信する。
そして、これらについて応答信号を受信できたら、ＤＡＴＡコマンドを送信してメール本文の送信を開始する。メール本文のデータはメールの長さに応じて複数のＩＰデータパケットに分割して送信することができる。メール本文のデータを全て送り終えたら、終了を示すコード（ピリオド）を送信した後、ＱＵＩＴコマンドで通信を完了させる。
なお、電子メールの送信が終わったらその時点でＴＣＰ通信コネクションを切断する。
【００３２】
〔電子メール送信制御プログラムの動作の概要〕
まず、ユーザがメーラＭを操作して電子メールを作成し、送信処理を開始すると（メーラＭの送信ボタンの押下等を行うと）、メーラＭは電子メールサーバ２との間にＴＣＰ通信コネクションを確立しようとする。
そして、ＴＣＰ通信コネクションが確立されたら、メーラＭは、前述のＳＭＴＰの手順に沿って、電子メールの送信処理を開始することになる（図３のＳｔｅｐ２）。
このメーラＭによるＴＣＰ通信コネクションの確立や電子メールの送信処理について、ＯＳが実行する処理を中断させた上で、後述する「横取り」を行うのがネットワークドライバ部Ｎである。
【００３３】
ネットワークドライバ部Ｎは、コンピュータ装置１においてＩＰデータパケットの送信処理が実行されると、この処理をフックする機能を備えている（図３のＳｔｅｐ１）。このフック機能は、何らかのアプリケーションプログラムがＯＳに対してＩＰデータパケットの送信を要求する処理を実行（送信関数をコール）した場合、その送信処理を中断すると共にＩＰデータパケットをネットワークドライバ部に引き渡す、というものである。このフック機能により、ネットワークドライバ部Ｎは、実際に送信処理が実行される前にＩＰデータパケットを「横取り」することができるようになる（図３のＳｔｅｐ３）。
メーラＭによって電子メールの送信処理が実行されると、ＯＳの通信ライブラリＴの送信関数がコールされるが、この電子メールもネットワークドライバ部Ｎによって横取りされることになる。
なお、このフック機能による横取りを可能な状態にするには、通常、コンピュータ装置１の起動後、電子メール送信制御プログラムの実行が開始された直後に一度フック機能を有効化するコマンドを実行しておけば、それ以降、送信関数がコールされるたびにネットワークドライバ部Ｎが「横取り」をすることが可能となる。
【００３４】
ネットワークドライバ部Ｎは、横取りしたＩＰデータパケットが、電子メールのデータやコマンド及びその応答信号以外の電子メールとは無関係のものであれば、そのＩＰデータパケットに対して何らの加工処理等を施すことなく、そのまま送信を許可する。
一方、横取りしたＩＰデータパケットが、電子メールに関するものであれば、そのＩＰデータパケットの宛先のＩＰアドレスＡ２（図５では「１０．１．１．１」）をコンピュータ装置１自身のＩＰアドレスＡ１（図５では「１０．０．０．１」）に書き換えると共に、宛先のポート番号Ｎ２（図５では「２５」）を、後述するプロキシーサーバ機能部（以下、プロキシーという。）Ｓの使用するポート番号Ｎ１（プロキシーＳがメーラＭから送信されてネットワークドライバ部Ｎによって転送されてくるＩＰデータパケットを受信するために使用するポート番号で、図５では「１０２１」）に設定する。なお、プロキシーＳと電子メールサーバ２が同一の番号を使用している場合には、ポート番号の書き換えは行わなくても構わない。
そして、前記書き換えた内容でＩＰデータパケットを送信するように通信ライブラリＴに通知する。以下、宛先のＩＰアドレス等を書き換えた上で送信する処理のことを「転送」と呼ぶことにする（図３のＳｔｅｐ４）。
【００３５】
なお、前記横取りしたＩＰデータパケットが電子メールに関するものかどうかは、当該ＩＰデータパケットの送信先又は送信元のポート番号がＳＭＴＰプロトコルで通常使用されるポート番号（通常は２５番）であるかどうかで判断すると良い。ただし、この場合、２５番以外のポート番号（例えば２５２５番）をＳＭＴＰプロトコル用に使用することが分かっているのであれば、当該２５番以外の番号を送信先ポート番号とするＩＰデータパケットを電子メールに関するものと判断しても良い。また、複数のポート番号のいずれか（例えば２５番と２５２５番）を送信先ポート番号とするＩＰデータパケットを電子メールに関するものと判断することもできる。
また、ポート番号以外のＩＰデータパケットの形式等から電子メールに関するものであるかどうかを判断するようにしても良い。前述のＳＭＴＰに従ってやり取りされるコマンドが有するデータ形式は予め標準化された固定的な形式であるから、コマンドのデータ形式を記憶しておいて、取得されたＩＰデータパケットの形式が当該記憶してある形式と一致するかどうかを比較して一致すれば電子メールに関するものである、と判断するようにしても構わない。
【００３６】
プロキシーＳは、ネットワークドライバ部Ｎに指示されて通信ライブラリＴが転送するＩＰデータパケットを受信する（図３のＳｔｅｐ５）。この場合、そのＩＰデータパケットには電子メールに関するデータやコマンドが含まれているので、図４に示すＳＭＴＰの通信手順に従って逐次応答信号の送信処理を実行する（図３のＳｔｅｐ６）。
このプロキシーＳによる応答信号の送信処理も、メーラＭによる電子メールの送信処理と同様に、ＯＳの通信ライブラリＴの送信関数をコールすることで実行されるが、ネットワークドライバ部Ｎは、この応答信号の送信処理についても横取りを行う（図３のＳｔｅｐ７）。
この場合、応答信号の送信元のＩＰアドレスは、コンピュータ装置自体のＩＰアドレスＡ１、ポート番号はプロキシーＳの使用するポート番号Ｎ１となっている。プロキシーＳが送信処理を実行したためである。
そこで、ネットワークドライバ部Ｎは、このＩＰアドレスＡ１とポート番号Ｎ１を電子メールサーバ２のＩＰアドレスＡ２及びポート番号Ｎ２（通常は２５番）に書き換えて転送するように通信ライブラリＴに通知し（図３のＳｔｅｐ８）、この通知を受けた通信ライブラリＴが応答信号をメーラＭ宛に送信する（図３のＳｔｅｐ９）。
【００３７】
この転送された応答信号は、メーラＭによって受信されるが、メーラＭは自己が電子メールの送信処理を実行した際の宛先のＩＰアドレスＡ２とポート番号Ｎ２（電子メールサーバ２のＩＰアドレスとポート番号）と同じＩＰアドレスとポート番号からの応答信号として受信することができる。このため、メーラＭは、あたかも電子メールサーバ２に対して電子メールを送信し、その応答信号を受信できたかのように認識することになる。
このように、ネットワークドライバ部ＮがメーラＭの送受信する電子メールに関連するＩＰデータパケットを横取りして転送することで、メーラＭに対する特別な機能の追加や設定の変更を行わなくても、メーラＭの動作にエラーが発生することはない。
つまり、メーラＭは、本発明の電子メール送信制御プログラムの有無に関係なく動作できることになる。
また、ネットワークドライバ部Ｎは、コンピュータ装置１から送出されようとする全てのＩＰデータパケットを対象として電子メールの横取りを行うため、メーラＭの種類を問わず確実に電子メールを捕捉することが可能となる。
【００３８】
この一連の動作で使用されるＩＰアドレスやポート番号の一例を示したのが図５である。
【００３９】
一方、ネットワークドライバ部Ｎによって転送された電子メールを受信したプロキシーＳは、その電子メールをポリシー判定部Ｐに通知する。このポリシー判定部Ｐは、いわゆるエージェントとして機能するプログラムであり、予めハードディスク１１２に記憶したポリシーデータＰＤ（ポリシーデータを記憶するネットワーク上のサーバ装置等から取得しても良い）を参照して、その電子メールについて判定を実施する。
例えば、特定のメールアドレスへの電子メールの送信を禁じる旨のポリシーが定義されている場合に、送信先メールアドレスが禁止されているメールアドレスであるかどうかを判定したり、添付ファイルが暗号化されていない電子メールの送信を禁じる旨のポリシーが定義されている場合に、添付ファイルの暗号化がされているかどうかを判定したりする。
【００４０】
このポリシーデータＰＤには複数のポリシーを定義することができ、例えば、添付ファイルを禁じるポリシーＡ、特定の相手に対する送信を禁じるポリシーＢおよびメール本文に特定の文字（例えば秘密）を含む電子メールの送信を禁じるポリシーＣの３つを定義することができる。
このように複数のポリシーが含まれている場合、ポリシー判定部Ｐは、各ポリシーに合致するか否かをそれぞれ判定し、その結果をプロキシーＳに通知する。
【００４１】
このポリシー判定部Ｐによる判定結果は、当該電子メールの送信の「許可」か「破棄」か、という二者択一であっても良いし、ユーザに送信するかどうかの判断を委ねる「ユーザ判断待ち」を加えた三者択一としても良い。また、「許可」と「ユーザ判断待ち」の二者択一とすることもできる。
ポリシー判定部Ｐの判定結果が「許可」であれば、その判定結果を含む判定情報を通知されたプロキシーＳは、電子メールの内容を加工等することなく、電子メールサーバ２宛にそのまま送出し、判定結果が「破棄」であれば、電子メールをそのまま破棄する（図３のＳｔｅｐ１１）。
なお、判定結果が「ユーザ判断待ち」となった場合には、ユーザ判定入出力部Ｕに対して、ユーザへの問いかけを行うＧＵＩの呼び出しを要求する。具体的には、ＧＵＩにおいて、ユーザに対し、「このメールはポリシー判定の結果、送信を許可されていないメールアドレスに対して送信しようとしています。このまま送信しますか？」といった内容の画面表示を行うと共に、判断結果の入力手段（「はい」、「いいえ」のボタン表示等）を表示する。
そして、このユーザの判断の結果を受けて、ポリシー判定部ＰはプロキシーＳに対して判定結果を通知する（ポリシー判定部Ｐに関連する処理は図３のＳｔｅｐ１０）。
なお、本発明における外部メールアドレスの検出に関連するポリシー判定部Ｐの動作については後段で詳述する。
【００４２】
プロキシーＳが電子メールをそのまま電子メールサーバ２に送信することに決定した場合、プロキシーＳが電子メールの送信処理を実行すると（図３のＳｔｅｐ１２−１）、通信ライブラリＴの送信関数がコールされるため、他の場合と同様にネットワークドライバ部Ｎが当該電子メールを横取りすることになる（図３のＳｔｅｐ１２−２）。
ただし、この場合、ネットワークドライバ部Ｎは、横取りしたＩＰデータパケットの送信元のＩＰアドレスとポート番号の組み合わせが、プロキシーＳが前記送信処理を行った際に使用したＩＰアドレスＡ１（図６では「１０．０．０．１」）とポート番号Ｎ３（プロキシーＳが電子メールサーバ２とＩＰデータパケットを送受信するために使用するポート番号で、図６では「９０００」）と一致すれば、何らの処理も行わずに（データの書き換えを行わずに）そのまま送信を許可する（スルーして送信する）（図３のＳｔｅｐ１２−３）。そして、通信ライブラリＴはこの電子メールを送信する（図３のＳｔｅｐ１２−４）。
ネットワークドライバ部Ｎがこの電子メールを横取りしてプロキシーＳ宛に転送してしまうと、いわゆるループバックの格好になって、電子メールサーバ２に対して電子メールを送ることができなくなるためである（Ｓｔｅｐ１２はＳｔｅｐ１１で電子メールを破棄しないと判定した場合の一連の処理）。
【００４３】
なお、ネットワークドライバ部Ｎが横取りした電子メールが、プロキシーＳが電子メールサーバ２宛に送ったものか、メーラＭが電子メールサーバ２宛に送ったものか、を区別するには、上記のようにプロキシーＳが送信処理を行ったときに使用した送信ポート番号Ｎ３をプロキシーＳから予め通知してもらっておき、横取りした電子メールの送信元ポート番号がプロキシーＳの送信元ポート番号Ｎ３と一致すればプロキシーＳが送信元で、そうでなければメーラＭが送信元である、と認識すれば良い。
【００４４】
この一連の動作で使用されるＩＰアドレスやポート番号の一例を示したのが図６である。
【００４５】
なおここでは、ポリシー判定部Ｐにおいて電子メールの送信を許可するか破棄するかまで判定してからその判定結果をプロキシーＳに通知するようにしているが、ポリシー判定部Ｐは通知された電子メールがポリシーに合致するものか否かについての判定結果のみを通知し、その判定の結果を受け取ったプロキシーＳの側で電子メールの送信を許可するか破棄するかを決定する、ということにしても構わない。
例えば、ポリシーデータにポリシーＡ、ポリシーＢおよびポリシーＣの３つのポリシーが含まれている場合に、ポリシー判定部Ｐの方では、各ポリシーに合致するか否かの結果のみをプロキシーＳに通知し、プロキシーＳがその３つのポリシーの各々に合致するかどうかの結果を総合的に判断した上で電子メールの送信を許可するかどうかを決定する、という実施形態でも構わない。
例えば、プロキシーＳの方で、２つ以上のポリシーに合致している場合にのみ電子メールを破棄するという決定をするようにしている場合、ポリシー判定部ＰからポリシーＡには合致しないがポリシーＢおよびポリシーＣには合致するという判定結果を受けた場合には、２つ以上のポリシーに合致するため、プロキシーＳは電子メールを破棄するという決定を行い、ポリシー判定部ＰからポリシーＡとポリシーＢには合致しないがポリシーＣには合致するという判定結果を受けた場合には、１つのポリシーにしか合致しないため、プロキシーＳは電子メールの送信を許可するという決定を行う、といった方法でも構わない。
また、処理時間の短縮のために複数のポリシーに優先度を設けておき、優先度の高いポリシー（例えばポリシーＡ）から順番にそのポリシーに合致しているかどうかを判定していって、優先度の高いポリシーに合致していると判断されればその時点で判定を打ち切って（その他の優先度の低いポリシーについての判定を行わずに）、優先度の高いポリシーに合致しているという判定結果のみをプロキシーＳに通知するといった方法を用いても構わない。
【００４６】
つまり、ポリシー判定部Ｐは、プロキシーＳが電子メールの送信を許可するか破棄するかを決定しうる情報である判定情報をプロキシーＳに対して送信すれば良いのであり、必ずしもポリシー判定部Ｐで電子メールの送信を許可するかどうかまで判定しなくても構わない。
【００４７】
このように、プロキシーＳは、ポリシー判定部Ｐによる判定結果に応じて、電子メールを破棄するか送信するかを決定するが、電子メールを送信する場合には、ユーザに特段の通知を行う必要はない。ユーザはメーラＭにおいて電子メールの送信処理を実行し、その処理がエラーなく完了したことを見届ければそれで足りるからである。
一方、プロキシーＳが電子メールを破棄した場合には、そのことを何らかの形でユーザに通知することが望ましい。なぜならば、ユーザはメーラＭで電子メールの送信処理を実行し、エラーなく完了したことを見届けているため、電子メールを確かに送信したつもりになっているからである。
【００４８】
そこで、プロキシーＳは、ポリシー判定部Ｐから通知された判定結果に応じて電子メールを破棄した場合、当該電子メールを破棄した旨の破棄通知用電子メールを新たに作成すると良い。破棄通知用電子メールの宛先電子メールアドレスはユーザの使用する電子メールアドレス（破棄した電子メールの送信元メールアドレス）である。プロキシーＳは、この破棄通知用電子メールを電子メールサーバ２宛に送信することが望ましい（図３のＳｔｅｐ１３−１）。
この場合にも、応答信号などと同様に、ネットワークドライバ部Ｎが当該破棄通知用電子メールを横取りするが（図３のＳｔｅｐ１３−２）、この破棄通知用電子メールは、送信元のＩＰアドレスとポート番号がプロキシーＳのＩＰアドレスＡ１とポート番号Ｎ３であるので、スルーしてそのまま送信される（図３のＳｔｅｐ１３−３および４）。
このようにすることで、メーラＭは、電子メールサーバ２から当該破棄通知用電子メールを受信することができる（Ｓｔｅｐ１３はＳｔｅｐ１１で電子メールを破棄すると判定した場合の一連の処理）。
【００４９】
なお、この破棄通知用電子メールの本文には、破棄された電子メールのメール本文の内容を引用しておくことが望ましい。ユーザに対して、破棄された対象がどの電子メールであったかを知らせるためである。
また、破棄した理由についても、本文に記載しておくことが望ましい。ユーザが電子メールを再編集して送信等する際に、その破棄の理由等を参照できれば、その理由を解消した上で再送信することができるためである。
さらに、破棄通知用電子メールのヘッダの領域（例えば、「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ」や「Ｒｅｆｅｒｅｎｃｅｓ」等が記載された領域）に、破棄した電子メールのヘッダの領域に格納されていた「Ｍｅｓｓａｇｅ−Ｉｄ」の値を転記しておくようにしても良い。このようにすれば、メーラＭを操作して送受信済みの電子メールを並べ替え処理等した場合に、破棄された送信済み電子メールと破棄通知用電子メールとが連続した位置関係になるので、ユーザが容易に確認可能となり至便である。
【００５０】
〔本発明におけるポリシー判定部Ｐの詳細な動作内容〕
ポリシー判定部Ｐでは、ユーザの指定等に応じて様々なポリシーを設定することが可能であり、前述の添付ファイルに関するポリシー等がそれに該当する。
本発明では、以下で説明するポリシー（図７）が用いられる。
なお、以下で説明するポリシーは「外部メールアドレス混入防止ポリシー」と呼ぶ。
【００５１】
まず、ポリシー判定部Ｐでは、プロキシーＳから引き渡された電子メールに含まれる宛先のメールアドレスの総宛先数を取得する（図７の処理１）。
総宛先数は、電子メールの宛先である「Ｔｏ：」や「Ｃｃ：」等にカンマ「，」や「；」等で区切って羅列されたメールアドレスの数を数えることによって取得することができる。
【００５２】
次に、宛先の各メールアドレスが外部メールアドレスに当たるかどうかを判定していく。この判定に当たっては、同じ事業体に属するメールアドレスとして予め記憶されているドメイン名を有するかどうかで判断することができる（図７の処理２）。
この場合のドメイン名とはメールアドレス中に含まれる「＠」マークよりも後段の文字列を指し、例えば、「ｓｅｉ．ｃｏ．ｊｐ」といった文字列である。
通常、同じ事業体に属するメールアドレス（以下、「内部メールアドレス」という。）は同じドメイン名を有するので、送信元のメールアドレスと同一のドメイン名を有するメールアドレス以外を外部メールアドレスと判定する方法を用いることもできるが、同じ事業体に属していても部署等によって異なるメールアドレスを使うこともあるし、複数のドメイン名のメールアドレスを使い分ける場合もある。また、例えば親会社と子会社のように、異なるドメイン名を使用しているが、実質的には同じ事業体に属すると判断できる場合もある。
そこで、内部メールアドレスとみなして良い（外部メールアドレスとは判断しない）ドメイン名を予めユーザ等に登録させて記憶させておくことが望ましい。
【００５３】
図８は、当該内部メールアドレスを示すドメイン名の内部ドメインテーブルの一例を示す図である。
このテーブルにおいては、「ａａａａａ．ｊｐ」と「ｂｂｂｂｂ．ｊｐ」と「ｃｃｃｃｃ．ｊｐ」の３つのドメイン名が同じ事業体に属する内部メールアドレスのドメイン名として登録されている。
本発明では、この内部ドメインテーブルをコンピュータ装置１のハードディスク１１２等に記憶させておいて、宛先の各メールアドレスが外部メールアドレスに当たるかどうかを順次判定していく。
【００５４】
この処理２によって、宛先のメールアドレスの中に外部メールアドレスが含まれていない場合には、ポリシー判定部Ｐは処理を終了し、この電子メールの送信を許可する旨をプロキシーＳに通知する。
一方、全ての宛先のメールアドレスについて判定した結果、外部メールアドレスが含まれていると判断された場合には、その外部メールアドレスの数である混入数を取得する（図７の処理３）。
なお、この処理３までの変形例として、処理１で取得される総宛先数が所定数（例えば１０個）未満等ならその時点で処理を終了するようにしても良い。総宛先数が少ない場合には、ユーザが一目で見分けられる可能性が高いので、外部メールアドレスの混入の有無を判断しなくても構わないと考えられるためである。
【００５５】
処理２では、例えば、宛先のメールアドレスが図９のように１５個ある場合、それぞれについて、前記内部ドメインテーブルのドメイン名と一致するかどうかを判定していく。
この場合、１０個目のメールアドレス「ｐ１１１１１＠ｍｍｍｍｍ．ｊｐ」が内部ドメインテーブルのドメイン名と一致しないため、このメールアドレスを外部メールアドレスと判定する。
１５個全てのメールアドレスについて判定を完了した結果、外部メールアドレスはこのメールアドレス１つだけなので、混入数は１と算出される。
【００５６】
そして、取得された混入数と、図１０の判定テーブルで総宛先数毎に設定された閾値とを比較し、混入数が閾値を超えるか否か判定する（図７の処理４）。
図９に示す例であれば、総宛先数１５に対して混入数は１であるから、前記判定テーブルに設定された閾値「２」を超えない。従って、ポリシー判定部Ｐは、この電子メールをそのまま送信するべきではない、と判定する（図７の処理５）。
なお、この場合の判定テーブルとは、総宛先数毎に混入数の閾値を設定したものであり、混入数がこの閾値を超えるかどうかで電子メールをそのまま送信しても良いかどうかを判断する。
図１０の判定テーブルでは、総宛先数が４以下で閾値を０としているため、混入数が最低の１であっても必ず閾値を超える。従って、総宛先数が４つ以内であれば外部メールアドレスの数に無関係に電子メールの送信を許可する。
そして、総宛先数が５以上９以下では閾値を１としているため、外部メールアドレス数が１つの場合にのみ閾値を超えない。従って、例えば総宛先数が８つに対して外部メールアドレスが１つ混入している場合は送信を許可しないが、外部メールアドレスが２つ以上混入していれば送信を許可する。
【００５７】
このように、図１０のような判定テーブルを用いることで、多数の総宛先数に僅かな外部メールアドレスが混入しているケースを検出することが可能になる。
なお、このような判定テーブルを用いる方法ではなく、事前に設定した割合（総宛先数等に対する割合）を超えるかどうかで判定する方法を用いても良い。
例えば、割合を２割と設定しておけば、図９のように総宛先数が１５個であれば閾値は３となり、外部メールアドレスの混入数が３個以下であれば電子メールの送信を許可しない、と判定することが可能になる。
このような方法は判定テーブルを用いる方法に比べて細やかな設定をすることができない反面、処理が単純でユーザ等がいちいちテーブルを設定する手間が省けるという利点がある。
【００５８】
また、閾値についても、総宛先数に応じて変更するのではなく固定の値としても構わない。例えば閾値を２や３に固定する方法である。
その場合、まず総宛先数が所定数（例えば１０個）を超えるかどうかを判断し、もし所定数を超えるなら（例えば総宛先数が１５個なら）、次に混入数を取得し、その混入数が閾値（例えば２個）を超えるかどうかを判定して、その結果に応じて電子メールの送信を許可するかどうかを決定するようにすれば良い。混入数が１つなら警告の対象となるが、混入数が５つならそのまま送信を許可する、といった方法である。
【００５９】
また、ユーザに対する警告頻度が大きく煩わしいような場合には、総宛先数に関係なく外部メールアドレスの混入数が１つだけのときのみ電子メールの送信を許可しないようにしても良い。例えば総宛先数が所定数（例えば１０個）以上でかつ混入数が１つ（閾値は１）のみ、といった場合にのみ電子メールの送信を許可しないようにしても構わない。
つまり、混入数の閾値等の設定については、ユーザの業務形態等に応じて適宜設定すれば良く、多数の宛先メールアドレスの中に僅かな外部メールアドレスが混入しているケースのみを効果的に検出できるような構成であれば良い。
【００６０】
また、混入数の閾値や総宛先数の閾値等の設定は、ユーザが単位期間当たり（例えば１日や１週間当たり）に送信する電子メールの総数に応じて、ユーザ毎に変動させるようにしても良い。
例えば、１日あたりに送信する電子メールの総数が１００通に満たないユーザについては、総宛先数が１０個以上でなければ「外部メールアドレス混入防止ポリシー」の判定対象外とするが、１日あたりに送信する電子メールの総数が１００通を超えるユーザについては、総宛先数が１０個以下でも「外部メールアドレス混入防止ポリシー」の判定対象とする、といった方法を用いても構わない。
電子メールの送信数が多いユーザほど、１通の電子メールの作成や宛先の確認に要する時間が短いため、注意散漫になりがちでミスが起きやすい、といった点に配慮するためである。
【００６１】
また、逆に、電子メールの送信数が多いユーザほど頻繁に警告が出てしまって煩わしい、といった事態を避けるために、１日あたりに送信する電子メールの総数が多いユーザほど混入数の閾値を小さくして警告が出る頻度が小さくなるようにする、といった方法を用いても構わない。
なお、単位期間当たりの電子メールの送信数は、例えばプロキシーＳに送信数を勘定するカウンタを設けておいて、ネットワークドライバ部Ｎが電子メールを横取りする度にカウンタ値をインクリメントするようにすれば良い。また、複数のユーザが電子メールを使用しているような場合には送信元メールアドレス毎にカウンタを設けても良い。
【００６２】
〔判定結果のユーザへの通知（警告）方法〕
ポリシーデータＰＤには、前述の「外部メールアドレス混入防止ポリシー」以外のポリシーを設定することも可能であるから、ポリシー判定部ＰはポリシーデータＰＤに設定された全てのポリシーについて判定を行う。
従って、例えば外部メールアドレスが混入していないような電子メールであっても送信を許可しないこともある。
【００６３】
ここでは、「外部メールアドレス混入防止ポリシー」で電子メールの送信を許可しないと判定された場合のポリシー判定部Ｐによるユーザへの通知（警告）方法について説明する。
図１１（ａ）は、ポリシー判定部Ｐにおいて「外部メールアドレス混入防止ポリシー」で判定した結果、送信を許可されない電子メールであるとの判定結果が通知された場合のユーザへの警告画面の一例を示す図である。
警告画面に表示する文字列や図形等はこの例以外のものであっても良いが、図１１（ａ）にあるようにどのポリシーに反するのか、をユーザに通知することが望ましい。
また、送信が許可されなかった理由についても具体的にユーザに通知すると親切である。
なお、この場合、検出した外部メールアドレス自体を一覧で表示するようにしても良い。ユーザが意図しない相手であるかどうかを瞬時に判断できる点で便利である。
【００６４】
そして、この警告画面には、最下段においてユーザの操作を受け付けるボタンが用意されている。この例では、「メール破棄」「そのまま送信」に加えて「外部メールアドレスを削除して送信」の３つのボタンが表示されている。
この場合、ユーザが「メール破棄」を選択すれば、ポリシー判定部Ｐは横取りした電子メールを破棄する旨の決定を行ってプロキシーＳに通知する。プロキシーＳは当該通知に応じて電子メールを破棄し、破棄通知メールを電子メールサーバ２宛に送信する。
一方、ユーザが「そのまま送信」を選択すれば、ポリシー判定部Ｐは横取りした電子メールの送信を許可する旨の決定を行ってプロキシーＳに通知する。プロキシーＳは当該通知に応じて電子メールをスルーして電子メールサーバ２宛に送信する。
【００６５】
この２つの選択肢のみでも構わないが、本発明ではユーザの利便性を高めるために「外部メールアドレスを削除して送信」という３つ目のボタンを用意してある。ユーザがこのボタンを選択した場合、ポリシー判定部ＰはプロキシーＳに対して、横取りした電子メールから外部メールアドレスを除外するように通知する。
当該通知を受けたプロキシーＳは電子メールの宛先メールアドレスのうち外部メールアドレスを削除して宛先メールアドレスが内部メールアドレスのみとなるように自動的に編集してから電子メールを電子メールサーバ２宛に送信する。
同じ事業体に属するメンバーにのみ通知すべき内容を含んだ電子メールを作成した直後に警告画面を見たユーザは、このボタンを選択することで、いちいち電子メールを一旦破棄して再編集・再送信をしなくても簡単に誤りを訂正することができ至便である。
【００６６】
なお、図１１（ｂ）のように削除すべき外部メールアドレスをユーザに選択させるような画面表示をするようにしても構わない。
外部メールアドレスが複数の場合、内容によっては送信が可能な相手がいるかもしれないので、そういった外部メールアドレスは除外の対象外とすることが可能になり、ユーザの利便性がさらに向上する。
【００６７】
〔他の実施形態〕
第１の実施形態では、ポリシーの判定等を行うプログラムをメーラＭとは別のプログラムとしているが、メーラＭに付属したプログラム（例えばメーラＭのプラグインソフトウェアのプログラム）としても構わない。
異なる種類のメーラＭを処理の対象とすることはできないが、メーラＭの機能を向上させるという点で有用である。
また、特定のメーラＭの付属プログラムにすれば、第１の実施形態のように、メーラＭがＯＳのＴＣＰ通信ライブラリの送信関数をコールするよりも前の時点で（例えば、メーラＭに用意されているメール送信ボタンを押下した直後の時点で）、ポリシー判定部Ｐで実施するのと同様の「外部メールアドレス混入防止ポリシー」に照らした判定を行うことが可能となり、電子メールの破棄をすることなくユーザに電子メールの再編集をさせることができる、という利点がある。
【００６８】
また、ポリシー判定部Ｐで「外部メールアドレス混入防止ポリシー」に照らした判定を行う対象となる電子メールを、返信の電子メールに限定するようにしても良い。
最初に電子メールを作成して送信するユーザは、１つ１つ宛先を指定するため間違いが起き難いが、受信したメールへの返信の場合には、宛先のメールアドレスを丁寧にチェックしないことが多くミスが起きやすいと考えられるからである。
なお、返信の電子メールであるかどうかは、例えば電子メールのタイトルの先頭に「Ｒｅ：」の文字が含まれるかどうかで判断しても良いし、ヘッダの領域に「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ」や「Ｒｅｆｅｒｅｎｃｅｓ」等が記載されていれば返信であると判断するようにしても良い。
【００６９】
なお、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００７０】
１コンピュータ装置、１０１ＣＰＵ、１１１メモリ、１１２ハードディスク、１２１通信インタフェース、２電子メールサーバ
Ｍ電子メール送信プログラム、Ｎネットワークドライバ部、Ｓプロキシーサーバ機能部、Ｐポリシー判定部、ＰＤポリシーデータ、Ｕユーザ判定入出力部、ＴＴＣＰ／ＩＰ通信ライブラリ

【特許請求の範囲】
【請求項１】
コンピュータ装置外部に送出されようとする電子メールを検出する検出ステップと、
前記電子メールの送信先メールアドレスが以下の条件（１）及び（２ａ）に合致するかどうか又は条件（１）及び（２ｂ）に合致するかどうかを判定する判定ステップと、
前記判定の結果、条件に合致していれば、電子メールの送信処理を中断してユーザに警告を行う警告ステップと
を前記コンピュータ装置に実行させるための電子メール送信制御プログラム。
（１）検出された電子メールの送信先メールアドレスの総数である総宛先数が所定数以上である。
（２ａ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記総宛先数又は所定数に占める割合が所定割合以下である。
（２ｂ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記所定数よりも小さい閾値以下である。
【請求項２】
前記判定ステップは、前記条件（２ｂ）の閾値を前記総宛先数又は所定数毎に設定した判定テーブルを記憶する記憶ステップを備え、前記混入数と当該判定テーブルの閾値との比較によって前記条件（２ｂ）に合致するかどうかを判定する請求項１に記載の電子メール送信制御プログラム。
【請求項３】
前記検出ステップでは、ユーザが受信した電子メールに対する返信の電子メールのみを検出する請求項１又は２に記載の電子メール送信制御プログラム。
【請求項４】
前記条件（１）の所定数は、単位期間当たりに送信される電子メールの総数が大きいほど小さい数に設定される請求項１乃至３のいずれか１つに記載の電子メール送信制御プログラム。
【請求項５】
前記条件（２ｂ）の閾値は１である請求項１乃至４のいずれか１つに記載の電子メール送信制御プログラム。
【請求項６】
前記警告ステップは、
ユーザに対して前記判定の結果に応じた表示を行う表示ステップと、
ユーザの操作を受け付ける操作受付ステップと、
前記操作受付ステップでユーザから受け付けた操作結果に応じて前記電子メールを送信するか否かを決定する決定ステップとを備える
請求項１乃至５のいずれか１つに記載の電子メール送信制御プログラム。
【請求項７】
前記決定ステップで前記電子メールを送信することに決定した場合、
前記操作受付ステップでユーザから受け付けた操作結果に応じて、前記電子メールの送信先に含まれる外部メールアドレスの全部又は一部を削除する宛先編集を行う削除ステップと、
前記宛先編集後の電子メールを送信する宛先編集後送信ステップとを前記コンピュータ装置に実行させる
請求項６に記載の電子メール送信制御プログラム。
【請求項８】
コンピュータ装置外部に送出されようとする電子メールを検出する検出ステップと、
前記電子メールの送信先メールアドレスが以下の条件（１）及び（２ａ）に合致するかどうか又は条件（１）及び（２ｂ）に合致するかどうかを判定する判定ステップと、
前記判定の結果、条件に合致していれば、電子メールの送信処理を中断してユーザに警告を行う警告ステップと
を前記コンピュータ装置に実行させる電子メール送信制御方法。
（１）検出された電子メールの送信先メールアドレスの総数である総宛先数が所定数以上である。
（２ａ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記総宛先数又は所定数に占める割合が所定割合以下である。
（２ｂ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記所定数よりも小さい閾値以下である。
【請求項９】
装置外部に送出されようとする電子メールを検出する検出ステップと、
前記電子メールの送信先メールアドレスが以下の条件（１）及び（２ａ）に合致するかどうか又は条件（１）及び（２ｂ）に合致するかどうかを判定する判定ステップと、
前記判定の結果、条件に合致していれば、電子メールの送信処理を中断してユーザに警告を行う警告ステップと
を実行するコンピュータ装置。
（１）検出された電子メールの送信先メールアドレスの総数である総宛先数が所定数以上である。
（２ａ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記総宛先数又は所定数に占める割合が所定割合以下である。
（２ｂ）検出された電子メールの送信先メールアドレスに同じ事業体以外に属する外部メールアドレスが含まれており、その外部メールアドレスの数である混入数が前記所定数よりも小さい閾値以下である。

【図１】