説明

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

【課題】ネットワーク構成やメール送信ソフトウェアに依存せず、容易に導入可能な電子メールの誤送信防止用の電子メール送信制御プログラムを提供する。
【解決手段】本発明にかかる電子メール送信制御プログラムは、電子メールを送信するためのソフトウェアであるメーラMと同じコンピュータ装置1で動作するものであり、メーラMが送信しようとした電子メールを横取りするネットワークドライバ部Nと、横取りした電子メールを送信すべきかどうか判定するポリシー判定部Pと、ポリシー判定部Pによる判定結果に応じて、電子メールを削除するか、そのまま電子メールサーバ装置2宛に送信するかどうかを決定するプロキシーサーバ機能部Sとを備えている。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子メール送受信用プログラムによって送信される電子メールの送信を制御し、誤送信を防止するための電子メール送信制御プログラムに関する。
【背景技術】
【0002】
近年、あらゆる分野における事業活動において電子メールの活用は必要不可欠となっており、1日に100通を超える電子メールをやり取りすることが常態化している。
電子メールは手軽で瞬時に送受信が可能であるという利点がある一方で、誤った内容で送信してしまったり、宛先を間違えたりするケースも多い。
【0003】
そこで、こういったいわゆる電子メールの誤送信を未然に防ぐ方法が複数提案されている。誤送信を防止する仕組みにはいくつか存在するが、(1)ユーザが扱うクライアント装置にインストールされた電子メール送受信用ソフトウェアにメール誤送信防止機能を追加するタイプ、(2)電子メールを集配信するメールサーバ装置側にメール誤送信防止機能を追加するタイプ、(3)クライアント装置とメールサーバ装置との間に誤送信された電子メールを捕捉する誤送信防止用装置を別途設けるタイプ等がある。
上記のうち、(1)のようなものとしては例えば特許文献1等がある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2007−193717号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記の(1)〜(3)のような仕組みには、それぞれ一定の問題点やデメリットが存在する。
まず、(1)のようにクライアント装置の電子メール送受信用ソフトウェアに機能を追加する場合、少なくとも、ユーザが使用する可能性のある複数の電子メール送受信用ソフトウェア全てについてメール誤送信防止機能を開発する必要があり、開発に多大なコストを要するという問題がある。
また、ユーザが電子メール誤送信防止機能を持たない電子メール送受信用ソフトウェアを使用した場合には、そもそも電子メールの送受信を防止することができない、という問題もある。
【0006】
(1)の問題点に鑑みて、(2)や(3)のようにメールサーバ装置側もしくはメールサーバ装置とクライアント装置との間に置いた誤送信防止用装置にメール誤送信防止機能を追加する方法を採用した場合、例えば、企業の社員がクライアント装置を社内LANに接続して使用する限り問題は起きないが、出張等で社外に持ち出して、別のメールサーバを経由して送信した場合には誤送信の防止は不可能となってしまう。
【0007】
本発明は、上記のような点に鑑みてなされたものであり、電子メール送受信用ソフトウェアの種類や、電子メールを送信した時の通信ネットワーク構成等に依存せずにメール誤送信を防止することが可能なプログラム等を提供することを目的とする。
【課題を解決するための手段】
【0008】
本発明にかかる電子メール送信制御プログラムは、電子メールの作成と送信を実行する電子メール作成送信部としてコンピュータ装置を動作させるための電子メール送信プログラムが搭載されたコンピュータ装置を、ネットワークドライバ部とプロキシーサーバ機能部とポリシー判定部として動作させるためのものであり、前記ネットワークドライバ部は、前記コンピュータ装置外部に送出されようとするIPデータパケットの送信を中断する中断手段と、当該IPデータパケットが電子メールであるかどうかを判断する判断手段と、その判断の結果電子メールであれば、当該IPデータパケットの送信先IPアドレスを前記コンピュータ装置のIPアドレスに設定すると共に送信先ポート番号を前記プロキシーサーバ機能部で使用されるポート番号に設定して送出する送出手段とを含み、前記プロキシーサーバ機能部は、前記ネットワークドライバ部から電子メールを受け取った旨を前記ポリシー判定部に対して通知するメール通知手段と、前記ポリシー判定部からの判定情報に基づいて、当該電子メールの破棄又は送信を決定する決定手段とを含み、前記ポリシー判定部は、ポリシーデータを取得する取得手段と、前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致するか否かを判定する判定手段と、その判定結果に応じた判定情報を前記プロキシーサーバ機能部に対して通知する情報通知手段とを含んでいる(請求項1)。
【0009】
この発明の電子メール送信制御プログラムは、電子メールの送信を行うための電子メール送信プログラムと同じコンピュータ装置に搭載されるため、ユーザがクライアント装置を持ち出して異なるネットワーク環境のもとでメールの送信を行う場合にもメールの誤送信を防止することが可能となる。
また、この電子メール送信制御プログラムは、電子メール送信プログラムとは異なる別のプログラムであり、前記コンピュータ装置から送出されようとする全ての電子メールを対象とすることができるため、電子メール送信プログラムの種類を問わず適用することが可能である。
【0010】
さらに、本発明によれば、電子メール送信制御プログラムが電子メール送信プログラムの動作に影響を与えることなくメールの誤送信を防止する役割を果たすことができる。つまり、電子メール作成送信部(電子メール送信プログラム)は、電子メール送信制御プログラムの有無に関わらず電子メールサーバ装置宛に電子メールを送信する処理を実行するだけでよく、電子メール送信制御プログラムの有無に応じて動作を切り替えたりする必要がない。
したがって、電子メール作成送信部(電子メール送信プログラム)側において特別な処理を追加したり設定変更等を行ったりする必要がないという点で大変有利である。また、電子メール作成送信部(電子メール送信プログラム)の動作に影響を与えないため、電子メール送信制御プログラムをインストールしたりアンインストールしたりした場合であっても、その都度電子メール送信プログラムの設定を変更する必要がなく、煩わしさがない。
【0011】
なお、前記ネットワークドライバ部には、前記プロキシーサーバ機能部に電子メールが受け渡された場合、電子メールを受け取った旨の応答信号を、その返信元IPアドレスを電子メールサーバ装置のIPアドレスに設定すると共に返信元ポート番号を前記電子メールサーバ装置のポート番号に設定して前記電子メール作成送信部宛に送出する手段をさらに備えさせても良い(請求項2)。
【0012】
前記応答信号の実際の返信元は同一コンピュータ装置内のプロキシーサーバ機能部であるから、この応答信号の返信元IPアドレスは前記コンピュータ装置のIPアドレス、返信元ポート番号はプロキシーサーバ機能部に使用されるポート番号である。しかし、前記電子メール作成送信部(電子メール送信プログラム)は電子メールを電子メールサーバ装置宛に送信して応答信号を待っている状態であるから、応答信号の返信元IPアドレス等が前記コンピュータ装置のIPアドレス等となっていると、自己の送信した電子メールに対する応答信号と認識することができなくなる。
そこで、前記応答信号の返信元IPアドレスを前記電子メールサーバ装置のIPアドレスに書き換えると共に、返信元ポート番号を電子メールサーバ装置のポート番号に設定することで、前記電子メール作成送信部(電子メール送信プログラム)に、電子メールサーバ装置が返信してきたと認識させることができるようになる。電子メール作成送信部(電子メール送信プログラム)から見ると、電子メールサーバ装置に対する電子メールの送信処理を実行した結果、電子メールサーバ装置から応答信号が送られてきたと判断できるため、正常に電子メールの送信処理を完了したと認識できることになる。
このように、電子メール作成送信部(電子メール送信プログラム)の動作には一切影響を与えずに(電子メール送信プログラムに本発明の電子メール送信制御プログラムの存在を意識させることなく)メール誤送信防止処理を実行することが可能となり至便である。
【0013】
なお、前記電子メール送信制御プログラムを前記コンピュータ装置を破棄通知機能部としても動作させるためのプログラムとし、その破棄通知機能部には、前記プロキシーサーバ機能部によって電子メールが破棄された場合、破棄された電子メールの送信元メールアドレスを送信先のメールアドレスとして設定した破棄通知用電子メールを作成する手段と、当該破棄通知用電子メールを前記電子メールサーバ装置宛に送出する手段とを含ませるようにすることが望ましい(請求項3)。
【0014】
電子メール送信プログラムを操作して電子メールを送信するユーザは、原則として電子メール送信プログラムの処理が正常に完了したら電子メールの送信が行われたものと考えるのが一般的であるので、電子メールを破棄した旨を別途通知することによって、送信しようとした電子メールが送信を許可されていないものであったことをユーザに認識させることができるようになる。
なお、この場合のユーザへの通知方法は、画面上に破棄した旨を文字で表示する方法や音声で知らせる方法等いろいろ考えられるが、ユーザが操作する電子メール送信プログラムが受信可能な形式の破棄通知用の電子メールを送信して通知する方法がより好適である。
電子メール送信プログラムには、送信しようとした電子メールの送信記録が残されているから、その電子メール送信プログラムに、その電子メールが破棄された旨も一緒に記録することで、ユーザは、電子メール送信プログラムの記録を確認するだけで電子メールの送信を試みたが破棄された、という一連の事実を一度に認識することができるようになる。
【0015】
なお、この場合の破棄通知用電子メールには、前記電子メールが破棄された理由が含まれているとさらに良い(請求項4)。
通常、送信を試みた電子メールが破棄された場合には、ユーザはその理由を認識した上で、電子メールを再編集し、破棄された原因を解消した上で再送信を行うと考えられるため、当該再編集を支援するために、破棄に至った理由をユーザに提示できると利便性がさらに向上する。
【0016】
なお、前記ポリシー判定部に、ユーザからの入力を受け付けるための表示を行う表示手段を備えさせ、当該表示手段に、前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致する場合に前記表示手段による表示を行わせるとともに、前記情報通知手段に、当該表示手段によって受け付けたユーザからの入力に応じた情報を前記判定情報に含めさせるようにしても構わない(請求項5)。
【0017】
前記ポリシー判定部が機械的にポリシーに合致するかどうかに基づいて電子メールを送信するかどうか決めるということだけではなく、ユーザに注意喚起してユーザに最終的な判断を委ねる仕組みも取り入れた方が、柔軟性が高まり利便性が向上するためである。
【0018】
なお、この電子メール送信制御プログラムを用いて実現されるコンピュータ装置の動作方法(請求項6)やコンピュータ装置自体も大変有用である(請求項7)。
【発明の効果】
【0019】
以上のように、本発明によれば、ネットワーク構成やメール送信用ソフトウェアに依存しない電子メールの誤送信防止機能を、容易に実現することが可能となる。
【図面の簡単な説明】
【0020】
【図1】本発明に係るコンピュータ装置のハードウェア構成の概要を示す模式図である。
【図2】本発明に係るコンピュータ装置に搭載されたプログラムの関係を示す模式図である。
【図3】本発明の各プログラム等の動作シーケンスの概要を示す模式図である。
【図4】SMTPの通信手順を示す模式図である。
【図5】本発明による電子メール送信制御方法において使用されるIPアドレスやポート番号の一例を示す図である。
【図6】本発明による電子メール送信制御方法において使用されるIPアドレスやポート番号の一例を示す図である。
【発明を実施するための形態】
【0021】
(第1の実施形態)
以下、本発明の第1の実施形態を、図面を参照しながら詳細に説明する。
図1は、メールの作成と送信を行うコンピュータ装置1(クライアント)のハードウェア構成を示す模式図である。
【0022】
〔構成の概要〕
CPU101は、コンピュータ装置1の備える機能を実現するためのコンピュータプログラムをハードディスク112から読み出してメモリ111にコピーして実行する機能を備えている。
本発明で実行される前記コンピュータプログラムとしては、コンピュータ装置1のオペレーティングシステム(以下、OSという。)のプログラム、電子メール送信プログラムM(以下、メーラという。)、及び電子メール送信制御プログラムが挙げられる。
この場合、前記電子メール送信制御プログラムは、ネットワークドライバ部N、プロキシーサーバ機能部S、及び、ポリシー判定部Pを含む構成となっている。
OSや電子メール送信制御プログラムは、コンピュータ装置1の電源がオンされた時点で自動的にハードディスク112から読み出されてメモリ111にコピーされ、常時実行可能な状態となるが、電子メール送信プログラムは、通常ユーザがメールの作成や送受信を行うタイミングで随時ハードディスク112から読み出されてメモリ111にコピーされて実行される。
【0023】
なお、OSには、電子メールを送受信するために必要なTCP/IP通信を実行するためのTCP/IP通信ライブラリが含まれており、予め用意されたAPI関数を用いてIPデータパケットの送受信を行うことができるようになっている。このAPI関数は、前記TCP/IP通信ライブラリとアプリケーションプログラムとの間のデータの受け渡しを行うために使用されるものである。
そして、このTCP/IP通信ライブラリによって、コンピュータ装置1から外部に送信すべきIPデータパケットを通信インタフェース121を介して他のコンピュータ装置(例えば電子メールサーバ2)に送信したり、他のコンピュータ装置からのIPデータパケットを通信インタフェース121を介して受信したりする機能が実現される。
【0024】
なお、図1ではコンピュータ装置1のCPUが1つだけの例を示しているが、複数のCPUによって構成されていても良いし、実現すべき機能のうちの一部については、その機能を実行可能な専用チップ(IC等)を備えるハードウェア構成としても良い。
【0025】
〔プログラムの動作〕
次に、図2と図3を用いて、本発明にかかる電子メール送信制御プログラムの動作を詳細に説明する。なお、使用されるIPアドレスやポート番号等に着目してそれらを図示したものが図5および図6になる。
実施形態に登場する各種プログラムはコンピュータ装置1に対する命令を組み合わせたものであるから、プログラムによって実現される動作や機能の主体はあくまでもコンピュータ装置1であるが、発明内容を把握しやすくするために、以下では各種プログラムを動作の主体として記載する。
【0026】
〔メーラMの設定〕
ユーザが使用するメーラMには電子メールの作成と送受信をする機能が備えられており、ユーザはメーラMを使用して作成した電子メールを送信することができる。
通常、メーラMは、使用する電子メールサーバのIPアドレスとポート番号を設定しなければ動作しない仕組みになっているので、メーラMには電子メールサーバ2のIPアドレスとポート番号が設定されている。
本発明では、このコンピュータ装置1に電子メール送信制御プログラムがインストールされているかどうかに関係なく、メーラMには常に電子メールサーバ2のIPアドレスA2とポート番号N2が設定されていれば良く、電子メール送信制御プログラムがインストールされている場合にもこの設定を変更する必要はない。
【0027】
通常、企業などの社員が社内LANに接続されたコンピュータ装置を使って電子メールの送受信を行う場合、ほとんど全ての社員は当該企業の情報システム部門が準備する同一の電子メールサーバを用いてメールの送受信を実施するため、全員が同じ設定を行えば済むことが多い。
本発明では、電子メール送信制御プログラムがインストールされているかどうかに関係なく電子メールサーバ2のIPアドレスA2とポート番号N2を設定すれば良い(電子メール送信制御プログラムがインストール/アンインストールされる前後で設定を変更しなくても良い)という点で導入が容易である、というのがメリットの1つである。
【0028】
もし、電子メール送信制御プログラムがインストール/アンインストールされる前後でメーラMの設定を変更しなければいけない仕組みとすると、社員それぞれに対して設定方法を教授する手間が発生するという不便さがあり、特に、社員の使用するコンピュータ装置毎に異なる設定をしなければいけない場合には、設定方法を教授する手間も大きくなってしまう。また、設定変更を忘れたり変更ミスをしたりする不慣れな社員が多い場合には、個々の社員に対して個別にサポートを行う必要性が生じるという問題もあるが、本発明では、そういった手間はほとんど発生しない。
【0029】
〔SMTPの基本手順を用いた電子メールの送信処理の概要〕
コンピュータ装置1のOSに含まれるTCP/IP通信ライブラリ(以下、通信ライブラリという。)Tを使用するために用意されるAPI関数には、例えば、メーラMによってメールの送信処理が実行される際に送信されるべきIPデータパケットの送信先やデータ内容等を引数としてコールされる送信関数や、特定のポート番号に対応付けて生成されるTCPのソケット等の識別子を引数として当該ポート番号宛に送信されたIPデータパケットを受信するためにコールされる受信関数等がある。
メーラMは、電子メールの送信処理を実行する場合、電子メールの送信先のメールアドレスやメール本文の文字列等を格納したテキストデータへのポインタや送信先のIPアドレス等を引数として送信関数をコールすることで、電子メールを送信することができる。
【0030】
なお、電子メールの送受信を行う場合、通常SMTP(Simple Mail Transfer Protocol)というプロトコルを使用することが多い。このSMTPでは、電子メールサーバと電子メール送受信用のクライアント装置との間で所定の通信手順に従ってやりとりが行われる。この通信手順を、図4を用いて説明する。
なお、このSMTPの通信手順はIETF(Internet Engineering Task Force)のRFC(Request For Comment)で標準仕様が定められており、以下はそのRFCで定められた手順と同じである。
まず、電子メールサーバとクライアント装置との間でTCPの通信コネクションが確立される。この場合、電子メールサーバのポート番号は通常25番が使用される。そして、以降のやりとりは、このTCP通信コネクション上で、IPデータパケット形式のデータを交換することで行われる。
【0031】
TCP通信コネクションが正常に確立されたら、まず、クライアント装置は、自身のドメイン名を格納したEHLOコマンドを送信する。電子メールサーバはこれに応じて応答信号を返信する。
クライアント装置は、EHLOコマンドに対する応答信号を受けたら、電子メールの送信元メールアドレス(通常はユーザのメールアドレス)を格納したMAILコマンドと宛先メールアドレスを格納したRCPTコマンドとをそれぞれ送信する。
そして、これらについて応答信号を受信できたら、DATAコマンドを送信してメール本文の送信を開始する。メール本文のデータはメールの長さに応じて複数のIPデータパケットに分割して送信することができる。メール本文のデータを全て送り終えたら、終了を示すコード(ピリオド)を送信した後、QUITコマンドで通信を完了させる。
なお、電子メールの送信が終わったらその時点でTCP通信コネクションを切断する。
【0032】
〔電子メール送信制御プログラムの動作の概要〕
まず、ユーザがメーラMを操作して電子メールを作成し、送信処理を開始すると(メーラMの送信ボタンの押下等を行うと)、メーラMは電子メールサーバ2との間にTCP通信コネクションを確立しようとする。
そして、TCP通信コネクションが確立されたら、メーラMは、前述のSMTPの手順に沿って、電子メールの送信処理を開始することになる(図3のStep2)。
このメーラMによるTCP通信コネクションの確立や電子メールの送信処理について、OSが実行する処理を中断させた上で、後述する「横取り」を行うのがネットワークドライバ部Nである。
【0033】
ネットワークドライバ部Nは、コンピュータ装置1においてIPデータパケットの送信処理が実行されると、この処理をフックする機能を備えている(図3のStep1)。このフック機能は、何らかのアプリケーションプログラムがOSに対してIPデータパケットの送信を要求する処理を実行(送信関数をコール)した場合、その送信処理を中断すると共にIPデータパケットをネットワークドライバ部に引き渡す、というものである。このフック機能により、ネットワークドライバ部Nは、実際に送信処理が実行される前にIPデータパケットを「横取り」することができるようになる(図3のStep3)。
メーラMによって電子メールの送信処理が実行されると、OSの通信ライブラリTの送信関数がコールされるが、この電子メールもネットワークドライバ部Nによって横取りされることになる。
なお、このフック機能による横取りを可能な状態にするには、通常、コンピュータ装置1の起動後、電子メール送信制御プログラムの実行が開始された直後に一度フック機能を有効化するコマンドを実行しておけば、それ以降、送信関数がコールされるたびにネットワークドライバ部Nが「横取り」をすることが可能となる。
【0034】
ネットワークドライバ部Nは、横取りしたIPデータパケットが、電子メールのデータやコマンド及びその応答信号以外の電子メールとは無関係のものであれば、そのIPデータパケットに対して何らの加工処理等を施すことなく、そのまま送信を許可する。
一方、横取りしたIPデータパケットが、電子メールに関するものであれば、そのIPデータパケットの宛先のIPアドレスA2(図5では「10.1.1.1」)をコンピュータ装置1自身のIPアドレスA1(図5では「10.0.0.1」)に書き換えると共に、宛先のポート番号N2(図5では「25」)を、後述するプロキシーサーバ機能部(以下、プロキシーという。)Sの使用するポート番号N1(プロキシーSがメーラMから送信されてネットワークドライバ部Nによって転送されてくるIPデータパケットを受信するために使用するポート番号で、図5では「1021」)に設定する。なお、プロキシーSと電子メールサーバ2が同一の番号を使用している場合には、ポート番号の書き換えは行わなくても構わない。
そして、前記書き換えた内容でIPデータパケットを送信するように通信ライブラリTに指示する。以下、宛先のIPアドレス等を書き換えた上で通信ライブラリTが電子メールを送信する処理のことを「転送」と呼ぶことにする(図3のStep4)。
【0035】
なお、前記横取りしたIPデータパケットが電子メールに関するものかどうかは、当該IPデータパケットの送信先又は送信元のポート番号がSMTPプロトコルで通常使用されるポート番号(通常は25番)であるかどうかで判断すると良い。ただし、この場合、25番以外のポート番号(例えば2525番)をSMTPプロトコル用に使用することが分かっているのであれば、当該25番以外の番号を送信先ポート番号とするIPデータパケットを電子メールに関するものと判断しても良い。また、複数のポート番号のいずれか(例えば25番と2525番)を送信先ポート番号とするIPデータパケットを電子メールに関するものと判断することもできる。
また、ポート番号以外のIPデータパケットの形式等から電子メールに関するものであるかどうかを判断するようにしても良い。前述のSMTPに従ってやり取りされるコマンドが有するデータ形式は予め標準化された固定的な形式であるから、コマンドのデータ形式を記憶しておいて、取得されたIPデータパケットの形式が当該記憶してある形式と一致するかどうかを比較して一致すれば電子メールに関するものである、と判断するようにしても構わない。
【0036】
プロキシーSは、ネットワークドライバ部Nに指示されて通信ライブラリTが転送するIPデータパケットを受信する(図3のStep5)。この場合、そのIPデータパケットには電子メールに関するデータやコマンドが含まれているので、図4に示すSMTPの通信手順に従って逐次応答信号の送信処理を実行する(図3のStep6)。
このプロキシーSによる応答信号の送信処理も、メーラMによる電子メールの送信処理と同様に、OSの通信ライブラリTの送信関数をコールすることで実行されるが、ネットワークドライバ部Nは、この応答信号の送信処理についても横取りを行う(図3のStep7)。
この場合、応答信号の送信元のIPアドレスは、コンピュータ装置自体のIPアドレスA1、ポート番号はプロキシーSの使用するポート番号N1となっている。プロキシーSが送信処理を実行したためである。
そこで、ネットワークドライバ部Nは、このIPアドレスA1とポート番号N1を電子メールサーバ2のIPアドレスA2及びポート番号N2(通常は25番)に書き換えて転送するように通信ライブラリTに通知し(図3のStep8)、この通知を受けた通信ライブラリTが応答信号をメーラM宛に送信する(図3のStep9)。
【0037】
この転送された応答信号は、メーラMによって受信されるが、メーラMは自己が電子メールの送信処理を実行した際の宛先のIPアドレスA2とポート番号N2(電子メールサーバ2のIPアドレスとポート番号)と同じIPアドレスとポート番号からの応答信号として受信することができる。このため、メーラMは、あたかも電子メールサーバ2に対して電子メールを送信し、その応答信号を受信できたかのように認識することになる。
このように、ネットワークドライバ部NがメーラMの送受信する電子メールに関連するIPデータパケットを横取りして転送することで、メーラMに対する特別な機能の追加や設定の変更を行わなくても、メーラMの動作にエラーが発生することはない。
つまり、メーラMは、本発明の電子メール送信制御プログラムの有無に関係なく動作できることになる。
また、ネットワークドライバ部Nは、コンピュータ装置1から送出されようとする全てのIPデータパケットを対象として電子メールの横取りを行うため、メーラMの種類を問わず確実に電子メールを捕捉することが可能となる。
【0038】
この一連の動作で使用されるIPアドレスやポート番号の一例を示したのが図5である。
【0039】
一方、ネットワークドライバ部Nによって転送された電子メールを受信したプロキシーSは、その電子メールをポリシー判定部Pに通知する。このポリシー判定部Pは、いわゆるエージェントとして機能するプログラムであり、予めハードディスク112に記憶したポリシーデータPD(ポリシーデータを記憶するネットワーク上のサーバ装置等から取得しても良い)を参照して、その電子メールについて判定を実施する。
例えば、特定のメールアドレスへの電子メールの送信を禁じる旨のポリシーが定義されている場合に、送信先メールアドレスが禁止されているメールアドレスであるかどうかを判定したり、添付ファイルが暗号化されていない電子メールの送信を禁じる旨のポリシーが定義されている場合に、添付ファイルの暗号化がされているかどうかを判定したりする。
【0040】
このポリシーデータPDには複数のポリシーを定義することができ、例えば、添付ファイルを禁じるポリシーA、特定の相手に対する送信を禁じるポリシーBおよびメール本文に特定の文字(例えば「秘密」)を含む電子メールの送信を禁じるポリシーCの3つを定義することができる。
このように複数のポリシーが含まれている場合、ポリシー判定部Pは、各ポリシーに合致するか否かをそれぞれ判定し、その結果をプロキシーSに通知する。
【0041】
このポリシー判定部Pによる判定結果は、当該電子メールの送信の「許可」か「破棄」か、という二者択一であっても良いし、ユーザに送信するかどうかの判断を委ねる「ユーザ判断待ち」を加えた三者択一としても良い。また、「許可」と「ユーザ判断待ち」の二者択一とすることもできる。
ポリシー判定部Pの判定結果が「許可」であれば、その判定結果を含む判定情報を通知されたプロキシーSは、電子メールの内容を加工等することなく、電子メールサーバ2宛にそのまま送出し、判定結果が「破棄」であれば、電子メールをそのまま破棄する(図3のStep11)。
なお、判定結果が「ユーザ判断待ち」となった場合には、ユーザ判定入出力部Uに対して、ユーザへの問いかけを行うGUIの呼び出しを要求する。具体的には、GUIにおいて、ユーザに対し、「このメールはポリシー判定の結果、送信を許可されていないメールアドレスに対して送信しようとしています。このまま送信しますか?」といった内容の画面表示を行うと共に、判断結果の入力手段(「はい」、「いいえ」のボタン表示等)を表示する。
そして、このユーザの判断の結果を受けて、ポリシー判定部PはプロキシーSに対して判定情報を通知する(ポリシー判定部Pに関連する処理は図3のStep10)。
【0042】
プロキシーSが電子メールをそのまま電子メールサーバ2に送信することに決定した場合、プロキシーSが電子メールの送信処理を実行すると(図3のStep12−1)、通信ライブラリTの送信関数がコールされるため、他の場合と同様にネットワークドライバ部Nが当該電子メールを横取りすることになる(図3のStep12−2)。
ただし、この場合、ネットワークドライバ部Nは、横取りしたIPデータパケットの送信元のIPアドレスとポート番号の組み合わせが、プロキシーSが前記送信処理を行った際に使用したIPアドレスA1(図6では「10.0.0.1」)とポート番号N3(プロキシーSが電子メールサーバ2とIPデータパケットを送受信するために使用するポート番号で、図6では「9000」)と一致すれば、何らの処理も行わずに(データの書き換えを行わずに)そのまま送信を許可する(スルーして送信する)(図3のStep12−3)。そして、通信ライブラリTはこの電子メールを送信する(図3のStep12−4)。
ネットワークドライバ部Nがこの電子メールを横取りしてプロキシーS宛に転送してしまうと、いわゆるループバックの格好になって、電子メールサーバ2に対して電子メールを送ることができなくなるためである(Step12はStep11で電子メールを破棄しないと判定した場合の一連の処理)。
【0043】
なお、ネットワークドライバ部Nが横取りした電子メールが、プロキシーSが電子メールサーバ2宛に送ったものか、メーラMが電子メールサーバ2宛に送ったものか、を区別するには、上記のようにプロキシーSが送信処理を行ったときに使用した送信ポート番号N3をプロキシーSから予め通知してもらっておき、横取りした電子メールの送信元ポート番号がプロキシーSの送信元ポート番号N3と一致すればプロキシーSが送信元で、そうでなければメーラMが送信元である、と認識すれば良い。
【0044】
この一連の動作で使用されるIPアドレスやポート番号の一例を示したのが図6である。
【0045】
なおここでは、ポリシー判定部Pにおいて電子メールの送信を許可するか破棄するかまで判定してからその判定結果をプロキシーSに通知するようにしているが、ポリシー判定部Pは通知された電子メールがポリシーに合致するものか否かについての判定結果のみを通知し、その判定の結果を受け取ったプロキシーSの側で電子メールの送信を許可するか破棄するかを決定する、ということにしても構わない。
例えば、ポリシーデータにポリシーA、ポリシーBおよびポリシーCの3つのポリシーが含まれている場合に、ポリシー判定部Pの方では、各ポリシーに合致するか否かの結果のみをプロキシーSに通知し、プロキシーSがその3つのポリシーの各々に合致するかどうかの結果を総合的に判断した上で電子メールの送信を許可するかどうかを決定する、という実施形態でも構わない。
例えば、プロキシーSの方で、2つ以上のポリシーに合致している場合にのみ電子メールを破棄するという決定をするようにしている場合、ポリシー判定部PからポリシーAには合致しないがポリシーBおよびポリシーCには合致するという判定結果を受けた場合には、2つ以上のポリシーに合致するため、プロキシーSは電子メールを破棄するという決定を行い、ポリシー判定部PからポリシーAとポリシーBには合致しないがポリシーCには合致するという判定結果を受けた場合には、1つのポリシーにしか合致しないため、プロキシーSは電子メールの送信を許可するという決定を行う、といった方法でも構わない。
また、処理時間の短縮のために複数のポリシーに優先度を設けておき、優先度の高いポリシー(例えばポリシーA)から順番にそのポリシーに合致しているかどうかを判定していって、優先度の高いポリシーに合致していると判断されればその時点で判定を打ち切って(その他の優先度の低いポリシーについての判定を行わずに)、優先度の高いポリシーに合致しているという判定結果のみをプロキシーSに通知するといった方法を用いても構わない。
【0046】
つまり、ポリシー判定部Pは、プロキシーSが電子メールの送信を許可するか破棄するかを決定しうる情報である判定情報をプロキシーSに対して送信すれば良いのであり、必ずしもポリシー判定部Pで電子メールの送信を許可するかどうかまで判定しなくても構わない。
【0047】
このように、プロキシーSは、ポリシー判定部Pによる判定結果に応じて、電子メールを破棄するか送信するかを決定するが、電子メールを送信する場合には、ユーザに特段の通知を行う必要はない。ユーザはメーラMにおいて電子メールの送信処理を実行し、その処理がエラーなく完了したことを見届ければそれで足りるからである。
一方、プロキシーSが電子メールを破棄した場合には、そのことを何らかの形でユーザに通知することが望ましい。なぜならば、ユーザはメーラMで電子メールの送信処理を実行し、エラーなく完了したことを見届けているため、電子メールを確かに送信したつもりになっているからである。
【0048】
そこで、プロキシーSは、ポリシー判定部Pから通知された判定結果に応じて電子メールを破棄した場合、当該電子メールを破棄した旨の破棄通知用電子メールを新たに作成すると良い。破棄通知用電子メールの宛先電子メールアドレスはユーザの使用する電子メールアドレス(破棄した電子メールの送信元メールアドレス)である。プロキシーSは、この破棄通知用電子メールを電子メールサーバ2宛に送信することが望ましい(図3のStep13−1)。
この場合にも、応答信号などと同様に、ネットワークドライバ部Nが当該破棄通知用電子メールを横取りするが(図3のStep13−2)、この破棄通知用電子メールは、送信元のIPアドレスとポート番号がプロキシーSのIPアドレスA1とポート番号N3であるので、スルーしてそのまま送信される(図3のStep13−3および4)。
このようにすることで、メーラMは、電子メールサーバ2から当該破棄通知用電子メールを受信することができる(Step13はStep11で電子メールを破棄すると判定した場合の一連の処理)。
【0049】
なお、この破棄通知用電子メールの本文には、破棄された電子メールのメール本文の内容を引用しておくことが望ましい。ユーザに対して、破棄された対象がどの電子メールであったかを知らせるためである。
また、破棄した理由についても、本文に記載しておくことが望ましい。ユーザが電子メールを再編集して送信等する際に、その破棄の理由等を参照できれば、その理由を解消した上で再送信することができるためである。
さらに、破棄通知用電子メールのヘッダの領域(例えば、「In−Reply−To」や「References」の領域)に、破棄した電子メールのヘッダの領域に格納されていた「Message−Id」の値を転記しておくようにしても良い。このようにすれば、メーラMを操作して送受信済みの電子メールを並べ替え処理等した場合に、破棄された送信済み電子メールと破棄通知用電子メールとが連続した位置関係になるので、ユーザが容易に確認可能となり至便である。
【0050】
〔比較例との対比〕
なお、本発明のようにプロキシーサーバ機能部Sをクライアント装置側に持たせる方法ではなく、ネットワークドライバ部Nで取得した電子メールがポリシーに合致するかどうかを判断させて、合致しなければそのまま電子メールサーバ装置に送信し、合致していれば破棄するか若しくはユーザに対して送信するかどうか判定させる、という方法も考えられる。つまり、クライアント装置側にプロキシーサーバ機能部Sを設けない方法である。
しかしながら、このような方法を採用すると、もし電子メールの送信可否の判断をユーザに委ねたい場合、電子メール送信プログラムと電子メールサーバ装置との間の通信手順を途中でストップさせてユーザに判断をさせなければならないため、例えばユーザが判断に迷っている間に、SMTPの通信手順やTCP/IP通信のレイヤにおいて送信タイムアウトといったエラーが起こる可能性がある。
つまり、電子メールの送信を行うべきかどうかを短時間でユーザに判断させなければうまく動作しないといった不利な点が存在することになる。
また、電子メール送信プログラムや電子メールサーバ装置との間の通信を強制的に中断させると、多数のクライアント装置との通信を行っている電子メールサーバ装置に対して大きな負荷をかけることになってしまう。
このように、電子メール送信プログラムや電子メールサーバ装置の動作に影響を与えるような仕組みはあまり望ましくない。
その点、本発明では、クライアント装置側にプロキシーサーバ機能部Sを設けているため、メーラMの実行した電子メールの送信処理自体にはエラーが発生しないように、通信処理を短時間で自動的に完了させることができる。
【0051】
なお、本発明の変形例として、ネットワークドライバ部Nが横取りして転送した電子メールを受信したプロキシーサーバ機能部Sが、電子メール送信プログラムに対して応答信号を送信する前にユーザに対して電子メールの送信を行うべきかどうかを判断させる、という方法も考えられる。
この方法では上記比較例と同様にユーザに短時間で判断させなければいけないというデメリットは存在するが(メーラMの通信を途中で中断するため)、クライアント装置側にプロキシーサーバ機能部Sを設けてあるので、電子メールサーバ2の通信を中断することがなく、電子メールサーバ2に負荷をかけないようにすることが可能になる。
【0052】
〔他の比較例との対比〕
なお、プロキシーサーバ機能部Sをクライアント装置側に設ける場合に、本発明のようなネットワークドライバ部Nを設けずに、電子メール送信プログラムにおいて指定するメールサーバのIPアドレスをプロキシーサーバ機能部SのIPアドレス(クライアント装置自体のアドレス)に設定して動作させる、といった方法も考えられる。
つまり、メーラMと電子メールサーバ2との間に電子メールを中継するためにプロキシーサーバ機能部Sを設け、メーラMが直接電子メールを送信する相手先のサーバを同一のクライアント装置で動作しているプロキシーサーバ機能部Sにする、という方法である。
しかし、この方法の場合、電子メール送信制御プログラムのインストールと共に、電子メール送信プログラムの設定変更も実施しなければいけないという点で手間がかかってしまう。
特に、1台のクライアント装置に複数のユーザが複数種類の電子メール送信プログラムをインストールして動作させている場合には、電子メール送信プログラム毎に設定変更を行う必要が生じ、発生する手間も大きくなってしまう。
また、電子メール送信制御プログラムをアンインストールした場合には、電子メール送信プログラムの設定を再び変更し、指定するメールサーバのIPアドレスを電子メールサーバ2のIPアドレスに再設定しなければ電子メールの送信ができなくなってしまうという問題があり、電子メール送信制御プログラム以外のプログラムの設定等に影響を与えることになってしまう。
その点、本発明では、クライアント装置内にプロキシーサーバ機能部Sと共にネットワークドライバ部Nを設けたことで、メーラMの設定を変更することなくメールの誤送信防止機能を実現することができるようになる。
【0053】
このように本発明の技術的効果は、メーラが動作するコンピュータ装置と同じコンピュータ装置内にプロキシーサーバ機能部Sと共にネットワークドライバ部Nを同時に備えることで初めて実現されるのであり、一方のみを備える場合に発生する問題点を全て解決することができるという点で、特有で顕著なものである。
【0054】
なお、今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【0055】
1 コンピュータ装置、 101 CPU、 111 メモリ、 112 ハードディスク、 121 通信インタフェース、 2電子メールサーバ
M 電子メール送信プログラム、 N ネットワークドライバ部、 S プロキシーサーバ機能部、 P ポリシー判定部、 PD ポリシーデータ、 U ユーザ判定入出力部、 T TCP/IP通信ライブラリ

【特許請求の範囲】
【請求項1】
電子メールの作成と送信を実行する電子メール作成送信部としてコンピュータ装置を動作させるための電子メール送信プログラムが搭載されたコンピュータ装置を、ネットワークドライバ部とプロキシーサーバ機能部とポリシー判定部として動作させるための電子メール送信制御プログラムであって、
前記ネットワークドライバ部は、
前記コンピュータ装置外部に送出されようとするIPデータパケットの送信を中断する中断手段と、
当該IPデータパケットが電子メールであるかどうかを判断する判断手段と、
その判断の結果電子メールであれば、当該IPデータパケットの送信先IPアドレスを前記コンピュータ装置のIPアドレスに設定すると共に送信先ポート番号を前記プロキシーサーバ機能部で使用されるポート番号に設定して送出する送出手段とを含み、
前記プロキシーサーバ機能部は、
前記ネットワークドライバ部から電子メールを受け取った旨を前記ポリシー判定部に対して通知するメール通知手段と、
前記ポリシー判定部からの判定情報に基づいて、当該電子メールの破棄又は送信を決定する決定手段とを含み、
前記ポリシー判定部は、
ポリシーデータを取得する取得手段と、
前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致するか否かを判定する判定手段と、
その判定結果に応じた判定情報を前記プロキシーサーバ機能部に対して通知する情報通知手段とを含むこと
を特徴とする電子メール送信制御プログラム。
【請求項2】
前記ネットワークドライバ部は、
前記プロキシーサーバ機能部に電子メールが受け渡された場合、電子メールを受け取った旨の応答信号を、その返信元IPアドレスを電子メールサーバ装置のIPアドレスに設定すると共に返信元ポート番号を前記電子メールサーバ装置のポート番号に設定して前記電子メール作成送信部宛に送出する手段をさらに備える
請求項1に記載の電子メール送信制御プログラム。
【請求項3】
前記電子メール送信制御プログラムは、
前記コンピュータ装置を破棄通知機能部として動作させるためのプログラムであり、
当該破棄通知機能部は、
前記プロキシーサーバ機能部によって電子メールが破棄された場合、破棄された電子メールの送信元メールアドレスを送信先のメールアドレスとして設定した破棄通知用電子メールを作成する手段と、
当該破棄通知用電子メールを前記電子メールサーバ装置宛に送出する手段とを含む
請求項1又は2に記載の電子メール送信制御プログラム。
【請求項4】
前記破棄通知用電子メールには、電子メールが破棄された理由が含まれている請求項3に記載の電子メール送信制御プログラム。
【請求項5】
前記ポリシー判定部は、
ユーザからの入力を受け付けるための表示を行う表示手段を備えており、
当該表示手段は、
前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致する場合に前記表示手段による表示を行い、
前記情報通知手段は、
当該表示手段によって受け付けたユーザからの入力に応じた情報を前記判定情報に含める
請求項1乃至4のいずれか1つに記載の電子メール送信制御プログラム。
【請求項6】
電子メールの作成と送信を実行する電子メール作成送信部としてコンピュータ装置を動作させるための電子メール送信プログラムが搭載されたコンピュータ装置を、ネットワークドライバ部とプロキシーサーバ機能部とポリシー判定部として動作させるための電子メール送信制御プログラムを用いた前記コンピュータ装置の動作方法であって、
前記ネットワークドライバ部は、
前記コンピュータ装置外部に送出されようとするIPデータパケットの送信を中断するステップと、
当該IPデータパケットが電子メールであるかどうかを判断するステップと、
その判断の結果電子メールであれば、当該IPデータパケットの送信先IPアドレスを前記コンピュータ装置のIPアドレスに設定すると共に送信先ポート番号を前記プロキシーサーバ機能部で使用されるポート番号に設定して送出するステップとを実行し、
前記プロキシーサーバ機能部は、
前記ネットワークドライバ部から電子メールを受け取った旨を前記ポリシー判定部に対して通知するステップと、
前記ポリシー判定部の判定結果に応じて、当該電子メールの破棄又は送出に決定するステップとを実行し、
前記ポリシー判定部は、
ポリシーデータを取得するステップと、
前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致するか否かを判定するステップと、
その判定の結果を前記プロキシーサーバ機能部に対して通知するステップとを実行すること
を特徴とする動作方法。
【請求項7】
電子メールの作成と送信を実行する電子メール作成送信部と、ネットワークドライバ部と、プロキシーサーバ機能部と、ポリシー判定部とを備える電子メール送信制御用のコンピュータ装置であって、
前記ネットワークドライバ部は、
前記コンピュータ装置外部に送出されようとするIPデータパケットの送信を中断する手段と、
当該IPデータパケットが電子メールであるかどうかを判断する手段と、
その判断の結果電子メールであれば、当該IPデータパケットの送信先IPアドレスを前記コンピュータ装置のIPアドレスに設定すると共に送信先ポート番号を前記プロキシーサーバ機能部で使用されるポート番号に設定して送出する手段とを含み、
前記プロキシーサーバ機能部は、
前記ネットワークドライバ部から電子メールを受け取った旨を前記ポリシー判定部に対して通知する手段と、
前記ポリシー判定部の判定結果に応じて、当該電子メールの破棄又は送出に決定する手段とを含み、
前記ポリシー判定部は、
ポリシーデータを取得する手段と、
前記プロキシーサーバ機能部から通知された電子メールが前記ポリシーデータに定められた条件に合致するか否かを判定する手段と、
その判定の結果を前記プロキシーサーバ機能部に対して通知する手段とを含むこと
を特徴とするコンピュータ装置。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2011−159244(P2011−159244A)
【公開日】平成23年8月18日(2011.8.18)
【国際特許分類】
【出願番号】特願2010−22626(P2010−22626)
【出願日】平成22年2月4日(2010.2.4)
【出願人】(504126112)住友電工システムソリューション株式会社 (78)
【出願人】(000002130)住友電気工業株式会社 (12,747)
【Fターム(参考)】