(57)【要約】【課題】  暗号化や電子署名を必要としないような電子メールには、暗号化対応の宛先や電子署名対応の宛先として登録されていても、個別に暗号化や電子署名を省略できるようにする。【解決手段】  暗号化の要否や電子署名の要否を示すコマンドあるいはキーワードを、電子メールのヘッダや本文に記述できるようにして、コマンドやキーワードの有無により暗号化や電子署名の要否を決定する。【選択図】    図７
2006157211.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの電子メールを送受信するメールサーバにおいて、
該電子メール中の所定のコマンドあるいはキーワードを抽出することにより、暗号化もしくは電子署名の要否を決定するための手段を設けたことを特徴とする、メールサーバ。
【請求項２】
前記コマンドあるいはキーワードの記憶手段を設けると共に、前記記憶手段のデータを遠隔に送出すると共に、遠隔から編集済みのデータを受信して、前記記憶手段のデータを上書きするための手段を設けたことを特徴とする、請求項１のメールサーバ。
【請求項３】
暗号化手段と復号手段及び電子署名手段と電子署名の検証手段とを備えることを特徴とする、請求項１または２のメールサーバ。
【請求項４】
クライアントからの電子メールを送受信するメールサーバ用のプログラムにおいて、
該電子メール中の所定のコマンドあるいはキーワードを抽出することにより、暗号化もしくは電子署名の要否を決定するための命令を設けたことを特徴とする、メールサーバ用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はメールサーバに関し、特に暗号化や電子署名の要否の管理に関する。
【背景技術】
【０００２】
電子メールを暗号化して安全に配送することや、電子メールに電子署名を施して、送信者を確認すると共に、通信路で改ざんされていないことを確認することが提案されている（特許文献１，２）。
【０００３】
暗号化の要否を自動的に決定するため、例えば宛先（送信先）毎の暗号化の要否を記憶しておくことが考えられる。しかしながら送信先が暗号化に対応しているからといって、無条件に送信メールを暗号化すると、メールサーバの負担が増加する。例えば暗号化対応や電子署名対応の宛先でも、暗号化せずにあるいは電子署名せずに送信しても問題ないようなものが存在する。これらを全て暗号化あるいは電子署名すると、メールサーバの負荷が重くなる。この一方で暗号化の要否や電子署名の要否は、電子メールの内容などによって定まる個別的なもので、メールサーバの側で一律に管理するのは難しいとの事情が有る。
【特許文献１】特開２００２−３６８８２３
【特許文献２】特開２００３−１９８６３２
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この発明の基本的課題は、暗号化あるいは電子署名の要否を個別にかつ柔軟に決定し得るようにして、メールサーバの負担を軽減することにある（請求項１〜４）。
請求項２の発明での追加の課題は、暗号化あるいは電子署名の要否の判別基準を、管理者などが容易に変更できるようにすることにある。
【課題を解決するための手段】
【０００５】
この発明のメールサーバは、クライアントからの電子メールを送受信するメールサーバにおいて、該電子メール中の所定のコマンドあるいはキーワードを抽出することにより、暗号化もしくは電子署名の要否を決定するための手段を設けたことを特徴とする。
【０００６】
好ましくは、前記コマンドあるいはキーワードの記憶手段を設けると共に、前記記憶手段のデータを遠隔に送出すると共に、遠隔から編集済みのデータを受信して、前記記憶手段のデータを上書きするための手段を設ける。
【０００７】
また好ましくは、暗号化手段と復号手段及び電子署名手段と電子署名の検証手段とを備える。
【０００８】
この発明のメールサーバ用のプログラムは、クライアントからの電子メールを送受信するメールサーバ用のプログラムにおいて、該電子メール中の所定のコマンドあるいはキーワードを抽出することにより、暗号化もしくは電子署名の要否を決定するための命令を設けたことを特徴とする。
【発明の効果】
【０００９】
この発明では、暗号化や電子署名が必要な宛先にのみこれらの処理を行うので、暗号メールサーバの負荷を軽減でき、また暗号化や電子署名の要否をクライアントが個別に指定できる（請求項１〜４）。
【００１０】
請求項２の発明では、暗号化や電子署名の要否を定めるコマンドやキーワードを、遠隔から管理者などが容易に編集できる。
【発明を実施するための最良の形態】
【００１１】
以下に本発明を実施するための最適実施例を示す。
【実施例】
【００１２】
図１〜図７に、実施例とその変形を示す。図１に、暗号メールサーバ２の構成を示すと、４は送受信部で、図示しないＬＡＮとの間で電子メールなどの送受信を行う。６は暗号化部で、クライアントから受信した電子メールを暗号化し、８は電子署名部で、クライアントから受信した電子メールに電子署名を施す。電子署名には、暗号文に対して電子署名を行うものと、平文に対して電子署名するクリア電子署名の２つの形態がある。１０は復号部で、ＬＡＮの外部などから受信した暗号化電子メールを平文に復号する。１２は検証部で、電子署名が施された電子メールを受信した際に電子署名を検証して、送信者を確認すると共に、通信路で改ざんがなされていないかどうかを確認する。
【００１３】
１４はメールボックスで、例えばクライアント毎に区分され、さらに送信用と受信用とに区分されている。１６はＨＴＴＰサーバで、暗号メールサーバ２の各種の設定データを、例えばＨＴＭＬ文書として管理者の端末へ送信し、管理者が編集した設定データを受信する。管理者の端末との間での設定データの送受信には、ＨＴＴＰ以外にＦＴＰ（ファイル・トランスファー・プロトコル）などを用いても良く、文書の形態はＨＴＭＬに限らず、ＸＭＬやそれ以外の文書形態でも良い。
【００１４】
１８は宛先テーブルで、送信先のドメイン名やメールアドレス、あるいはグローバルアドレスなどの単位で、暗号化の要否と電子署名の要否、並びに電子署名する場合の署名形態などを記憶する。２０はコマンド検出部で、クライアントから受信した電子メール中のヘッダや本文などを検索し、電子署名や暗号化の要否を指示するコマンド、あるいは電子署名や暗号化の要否に関するキーワードを検出して、暗号化あるいは電子署名の要否を決定する。コマンドテーブル２１は、これらのコマンドやキーワードを記憶する。２２は証明書テーブルで、暗号メールサーバ２やそのクライアントの、暗号化や電子署名用の公開鍵に関する証明書とそのデータとを記憶したテーブルである。宛先テーブル１８，コマンドテーブル２１，証明書テーブル２２のデータは、暗号メールサーバ２の設定データの一部であり、ＨＴＴＰサーバ１６を利用して、管理者の端末へ送信して編集することができる。テーブル１８，２１，２２のデータは、テーブル以外の他の形式で記憶しても良い。
【００１５】
図２に、暗号メールサーバ２を用いた電子メールシステムの構成を示す。なお図２において、「’」の無い符号を付した要素は送信側の要素を示し、「’」付きの符号を付した要素は受信側の要素を示し、符号の「’」以外の部分が同じ数字であれば、同じものである。ここでは暗号メールサーバ２から暗号メールサーバ２’などへ電子メールを送信するものとする。２３，２３’はＬＡＮで、ＬＡＮ２３，２３’にはインターネットファクシミリ装置２４，２４’を設け、これは、Ｇ３ファクシミリの送受信や電子メールなどの形式でのインターネットファクシミリの送受信を行うと共に、ＬＡＮ２３，２３’での共用プリンタ及び共用スキャナとして作用する。暗号メールサーバ２，２’は、例えばインターネットファクシミリ用の電子メールの暗号化や電子署名、並びにこれらの復号や検証に用い、暗号メールサーバ２，２’はインターネットファクシミリ装置２４，２４’内に組み込んでも良い。２５，２５’はパーソナルコンピュータなどのクライアント、２６，２６’は管理者の端末で、物理的にはパーソナルコンピュータなどとする。暗号メールサーバ２，２’は、クライアント２５，２５’などに対して、電子メールの暗号化や復号、電子署名やその検証を行うサーバとしても作用する。２７，２７’はルータで、２８はＷＡＮで例えばインターネットである。
【００１６】
実施例では、ＬＡＮ２３からの電子メールの送信は、暗号メールサーバ２を経由するものとするが、暗号メールサーバ２や暗号メールサーバ２’は、暗号化電子メールや電子署名付きの電子メールの送受信のみに用い、これ以外の電子署名無しで平文の電子メールの送受信には、鎖線で示す別のメールサーバ２９などを用いても良い。
【００１７】
この発明はメールサーバ２９を用いても実施でき、例えば、メールサーバ２９は暗号化や電子署名並びに復号や検証機能を有さないが、図１のコマンド検出部２０とコマンドテーブル２１とを備えて、クライアント２５やインターネットファクシミリ装置２４などから受信した電子メールに対して、暗号化や電子署名の要否を判別するものとする。そして暗号化や電子署名が必要な場合、暗号メールサーバ２へ転送し、暗号メールサーバ２で暗号化や電子署名を行う。暗号化も電子署名も行わない電子メールは、メールサーバ２９からルータ２７を介してＷＡＮ２８へ送信する。
【００１８】
図３に、メールサーバ用のプログラム３０を示す。このプログラムは暗号メールサーバ２などに実装されて暗号化や電子署名の要否を決定するために用いられ、コマンド検出命令３２は、暗号化や電子署名の要否を定めるコマンドやキーワードの検出を行うための命令である。コマンドとキーワードは極めて類似した概念なので、これらをまとめてコマンドと呼ぶことがある。暗号化命令３４は、暗号化要のコマンドやキーワードを検出した際に、暗号化部に暗号化の実行を要求する命令である。電子署名命令３６は電子署名要のコマンドやキーワードを検出した際に、電子署名部に電子署名を要求するための命令である。コマンド編集命令３８は、図１のコマンドテーブル２１などの設定データを送受信部から送出させ、かつ管理者の端末などで編集されたテーブルの設定データを受信した際に、元のテーブルを上書きするための命令である。
【００１９】
図４に宛先テーブル１８の内容を示すと、テーブルの各データは宛先のドメイン名や、メールアドレス、グローバルアドレスなどの見出しを有し、暗号化の要否と電子署名の要否並びに電子署名の形態を記載する。またこの宛先に対して暗号化を行う際の公開鍵や、これらの宛先からの電子署名を検証するための公開鍵を記載し、かつこれらの公開鍵に関する証明書データを記載する。証明書データには例えば、公開鍵を認証した認証局の名称や認証番号、並びにその有効期限などがある。オプションの欄には暗号化や電子署名に関する様々なオプションを記載し、例えば同じドメインの内部でも、特定のメールアドレスに対して暗号化や電子署名の要否を変更する場合などをオプションとして記載する。実施例では、宛先テーブル１８で暗号化要とされている宛先を暗号化対応の宛先と呼び、電子署名要とされている宛先を電子署名対応の宛先と呼ぶ。
【００２０】
図５はコマンドテーブル２１の例を示し、クライアントから受信した電子メールのヘッダや本文などを検索した際に、これらのコマンドやキーワードが検出されてると、それに従って暗号化や電子署名の要否を決定する。例えばコマンド「encode」は暗号化を要求するためのコマンドで、電子メールのヘッダに「encode」などの欄を設けて、これをＯＮにセットすると暗号化を行う。「signature」は電子署名の要否に関するコマンドである。「conf」はconfidenceの略で、暗号化のキーワードとして用いる。「secret」も同様のキーワードで、これらのキーワードがヘッダや本文に含まれると暗号化する。例えば「極秘」などのキーワードがあると、暗号化と電子署名の双方を行い、「plain」あるいは「平文」などのキーワードがあると、暗号化も電子署名も不要とする。図２のメールサーバ２９を用いる場合、例えば宛先欄に「To」あるいは「CC」として、暗号メールサーバ２を意味する「sec」（secureの略）が含まれていると、宛先が暗号化対応であれば暗号化し、電子署名対応であれば電子署名する。
【００２１】
コマンドテーブル２１のデータは、管理者の端末２６により編集できるので、どのようなコマンドやキーワードがあれば暗号化や電子署名を行い、どのような場合には暗号化も電子署名も行わないのかの管理者の方針に従って、暗号メールサーバ２を運用できる。
【００２２】
図６は証明書テーブル２２の例を示し、ローカルアドレスやアカウントの欄に記載のあるデータは、クライアント別の証明書に関する記載である。また共有／個別の区別は、共有の場合、暗号メールサーバの全てのクライアントに共有の証明書と、クライアント別の証明書の区別である。証明書テーブル２２には暗号化に用いる公開鍵や、復号に用いる秘密鍵、電子署名に用いる秘密鍵や検証に用いる公開鍵などを記載し、証明書ＩＤとして、これらの公開鍵を認証した認証局の名称や認証番号並びにその有効期限などを記載する。
【００２３】
暗号メールサーバ２はクライアント２５から電子メールを受信した際に、そのローカルアドレスやアカウントなどからクライアントを特定でき、クライアント別の証明書を利用できるかどうかを証明書テーブルにより判別する。クライアント別の証明書と共有の証明書のいずれをも利用できるクライアントの場合、特に指定がなければクライアント別の証明書を利用する。クライアント別の証明書を利用できないクライアントに対しては、共有の証明書を用いる。このようにして、どの証明書を用いて暗号化や電子署名を行うかを使い分ける。
【００２４】
図７に暗号化や電子署名の要否に関する決定アルゴリズムを示す。ステップ１でクライアントから着信した電子メールの有無をチェックし、ステップ２で送信先のドメイン名などから暗号化対応の宛先かどうかを判別する。暗号化対応の宛先の場合、ステップ３で、ヘッダや本文などでの暗号化を指示するコマンドあるいはキーワードの有無を判別し、これらのコマンドやキーワードがあれば、ステップ４で電子メールを暗号化する。暗号化対応の宛先でも、暗号化を指示するコマンドやキーワードが無い場合、電子メールの暗号化は行わない。
【００２５】
ステップ５で、電子署名対応の宛先かどうかを検査し、電子署名対応の場合、電子署名を要求するコマンドあるいはキーワードの有無をステップ６で検査し、これらが存在するとステップ７で電子署名する。電子署名対応の宛先でも、ステップ６で電子署名を要求するコマンドやキーワードが検出されない場合、電子署名を省略する。なお電子署名の形態は、宛先テーブルなどに記載のものを利用する。また電子署名の形態を特定するための、コマンドあるいはキーワードをヘッダや本文に記載できるようにして、ユーザの指定に応じて電子証明の形態を決定するようにしても良い。続いてステップ８で送信元アドレスをＬＡＮ内のローカルアドレスから、インターネットアドレスなどのグローバルアドレスに置換し、ステップ９で送信する。
【００２６】
図７のステップ２やステップ５は省略することができる。この場合、例えば暗号化や電子署名がクライアントにより要求されていると、宛先に問い合わせて暗号化用の公開鍵を取得し、あるいは電子署名の検証用の公開鍵などを送信する。そして個別に暗号化や電子署名の準備を行った後に、暗号化もしくは電子署名を行う。
【００２７】
実施例では以下の効果が得られる。
(1)  暗号化や電子署名が必要な宛先にのみこれらの処理を行うので、暗号メールサーバの負荷を軽減できる。
(2)  暗号化や電子署名の要否をクライアントが個別に指定できる。
(3)  暗号化や電子署名の要否を定めるコマンドやキーワードを、管理者が容易に編集できる。
【図面の簡単な説明】
【００２８】
【図１】実施例の暗号メールサーバのブロック図
【図２】実施例の暗号化メールサーバを組み込んだ電子メールシステムの構成図
【図３】実施例の暗号メールサーバ用のプログラムのブロック図
【図４】実施例での宛先テーブルを模式的に示す図
【図５】実施例でのコマンドテーブルを模式的に示す図
【図６】実施例での証明書テーブルを模式的に示す図
【図７】実施例での、暗号化や電子署名の要否の決定アルゴリズムを示すフローチャート
【符号の説明】
【００２９】
２  暗号メールサーバ
４  送受信部
６      暗号化部
８  電子署名部
１０  復号部
１２  検証部
１４            メールボックス
１６  ＨＴＴＰサーバ
１８  宛先テーブル
２０  コマンド検出部
２１  コマンドテーブル
２２  証明書テーブル
２３  ＬＡＮ
２４  インターネットファクシミリ装置
２５  クライアント
２６  管理者の端末
２７  ルータ
２８  ＷＡＮ
２９            メールサーバ
３０            メールサーバ用のプログラム
３２  コマンド検出命令
３４  暗号化命令
３６  電子署名命令
３８  コマンド編集命令
【図１】
2006157211.tif 000003
【図２】
2006157211.tif 000004
【図３】
2006157211.tif 000005
【図４】
2006157211.tif 000006
【図５】
2006157211.tif 000007
【図６】
2006157211.tif 000008
【図７】
2006157211.tif 000009