JP2006287976A - メールサーバー、メールクライアント及び電子メールシステム - Google Patents

Abstract

【課題】メールクライアントが電子メールの暗号化機能を持たない場合でも、電子メールを暗号化して所望の宛先に送信することを可能としつつ、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて電子メールの暗号化及びその送信について臨機応変な対応を可能とする。
【解決手段】管理すべき宛先への電子メールを受信蓄積し、要求に応じて電子メールをメールクライアント７０へ送信するメールサーバー６０において、受信した電子メールに電子署名がなされているか否かを検知する署名検知部６３と、電子メールの署名者の公開鍵を取得する公開鍵取得部６４と、電子署名がなされていると判定された場合に、公開鍵取得部６４が取得した署名者の公開鍵を使って電子署名の検証を行う署名検証部６５と、署名検証部６５による電子署名の検証結果を応答する署名検証結果応答部６６とを備えた。
【選択図】図４

Description

本発明は、メールサーバー、メールクライアント及び電子メールシステムに係り、より詳しくは、管理すべき宛先への電子メールを受信蓄積し、メールクライアントからの要求により蓄積した電子メールをメールクライアントへ送信するメールサーバー、メールサーバーに受信蓄積された宛先情報付きの電子メールを当該宛先情報に基づいて受信するメールクライアント、及びこれら両者を含んで構成された電子メールシステムに関する。

近年、公開鍵暗号技術、共通鍵暗号技術、および、メッセージダイジェスト技術を利用した暗号電子メールが実用されており、この暗号電子メールを利用することで、電子メールの秘匿や改竄防止、送信者認証の機能を実現することが可能となる。

このような暗号電子メールとしては、電子メールのＭＩＭＥ(Multipurpose Internet Mail Extension)機能を利用して暗号電子メールを取り扱えるようにしたＳ／ＭＩＭＥ(Secure MIME)やＰＧＰ／ＭＩＭＥ(Pretty GoodPrivacy MIME)の技術が利用されている。ここで、ＭＩＭＥについての技術内容は、ＩＥＴＦ(Internet Engineering Task Force)の技術標準である非特許文献１、２に規定されている。

まず、Ｓ／ＭＩＭＥには、現在バージョン２とバージョン３があり、その技術内容がそれぞれＩＥＴＦの技術標準である非特許文献３〜６に規定されている。また、ＰＧＰ／ＭＩＭＥの技術内容が、ＩＥＴＦの技術標準である非特許文献７、８に規定されている。

このうちＳ／ＭＩＭＥは、国際電気通信連合(ＩＴＵ: International Telecommunication Union)が規定する勧告Ｘ．５０９の公開鍵基盤を利用しており、ビジネスや電子商取引の分野で利用での適応性を持っている。Ｘ．５０９公開鍵基盤では、テンティティと呼ばれるユーザーや装置の名前およびメールアドレスと公開鍵との対応を認証局(CA: Certificate Authority)が保証し、認証局が、認証局の秘密鍵で、エンティティの名前やメールアドレスと公開鍵に対してデジタル署名した公開鍵証明書を発行する仕組みとなっている。

一方、ＰＧＰ／ＭＩＭＥは、Ｓ／ＭＩＭＥと異なり、ユーザーや装置であるテンティティの名前やメールアドレスと公開鍵との対応を、認証局ではなく他のエンティティが認証者となって保証するという仕組みを用いており、暗号電子メールを小さなグループや組織において手軽に利用する場合に適応性を持っている。

ところで、これらの暗号電子メールの機能は、メールサーバーではなく、メールクライアントに実装されていた。

例えば、Ｓ／ＭＩＭＥに対応したメールクライアントとして、米国Microsoft CorporationのOutlook Express（登録商標）や米国Netscape Communications CorporationのNetscape Messenger（登録商標）がある。また、ＰＧＰ／ＭＩＭＥに対応したメールクライアントとして、米国Network Associates社のＰＧＰフリーウェアがある。

これらのメールクライアントでは、電子メールの暗号化機能や署名機能は、すべてメールクライアント側に実装されており、メールクライアント側のソフトウェアが複雑となっていたため、携帯端末のような資源の限られたメールクライアントでは、暗号電子メール機能を実現することは困難であった。

また、これらのメールクライアントでは、暗号電子メールに必要な公開鍵の管理機能も、メールクライアントに実装されており、電子メールを暗号化する時に必要となる宛先の公開鍵や、電子メールの署名検証に必要となる送信元の公開鍵は、メールクライアント側の公開鍵レポジトリに登録されている必要があった。このため、多数の相手と暗号電子メールの交換を行なう場合には、公開鍵レポジトリに多数の公開鍵を登録しておかなければならず、公開鍵登録のために多くの資源を必要とした。

また、公開鍵に対しては、有効期限切れによる公開鍵の失効や、公開鍵の所有者の秘密鍵が暴露された等の理由により公開鍵が廃棄されていないかを確認し、公開鍵の有効性を検証することが必要であった。例えば、公開鍵をメールクライアント側で保持せず、ネットワーク上の公開鍵サーバーから取得する方法や公開鍵の有効性検証をネットワーク情報の公開鍵サーバーで行なう方法も提案されているが、その場合でも、メールクライアントに暗号化機能や署名機能が実装され、これらのサーバーから公開鍵を取得しサーバーに公開鍵の有効性検証を依頼する必要があった。

また、近年、メールクライアントではなく、ＷＥＢブラウザからメールの送受信機能を有するＷＥＢサーバーにアクセスし、メールの送受信を行なうＷＥＢメール機能が利用されている。例えば、このようなＷＥＢメール機能をもつサービスとして、米国Microsoft CorporationのHotmail（登録商標）がある。

ＷＥＢメールでは、ＷＥＢブラウザで入力した電子メールの内容と宛先指定がＨＴＴＰ(Hyper Text Transfer Protocol)により、ＷＥＢサーバーに送信される。ＷＥＢサーバーでは、ＨＴＴＰで受信した電子メールの内容と宛先情報から電子メールを生成し、ＳＭＴＰ(Simple Mail Transfer Protocol)で宛先に電子メール送信を行なう。

また、メールサーバーに受信した電子メールは、ＷＥＢサーバー上でＨＴＭＬ（Hyper Text Markup Language）に変換されＷＥＢブラウザの要求によりＨＴＴＰで送信される。

従来、このようなＷＥＢメールでは、暗号電子メールの機能をＷＥＢブラウザ自体が備えていないため、暗号電子メールを利用できず、秘匿性の高い内容のメールを暗号送信したり、受信メールの改竄検知を行なうことができなかった。

ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化に、ＳＳＬ(Security Socket Layer)などの通信路暗号技術を利用することが一般的に行われているが、この技術は、ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化であり、送受信される電子メール自体の暗号化ができなかったため、メール転送路上の秘匿の問題を解決できなかった。
Network Working Group, Request forComments: 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: MediaTypes, N. Freed, November 1996, http://www.ietf.org/rfc/rfc2046.txt Network Working Group, Request forComments: 2047 - MIME (Multipurpose Internet Mail Extensions) Part Three:Message Header Extensions for Non-ASCII Text, K. Moore, November 1996, http://www.ietf.org/rfc/rfc2047.txt Network Working Group, Request for Comments:2311 - S/MIME Version 2 Message Specification, S. Dusse, March 1998, http://www.ietf.org/rfc/rfc2311.txt Network Working Group, Request forComments: 2312 - S/MIME Version 2 Certificate Handling, S. Dusse, March 1998, http://www.ietf.org/rfc/rfc2312.txt Network Working Group, Request forComments: 2632 - S/MIME Version 3 Certificate Handling, B. Ramsdell, Editor,June 1999, http://www.ietf.org/rfc/rfc2632.txt Network Working Group, Request for Comments: 2633 - S/MIME Version 3 Message Specification, B. Ramsdell, Editor, June 1999, http://www.ietf.org/rfc/rfc2633.txt Network Working Group, Request for Comments: 1991 - PGP Message Exchange Formats, D. Atkins, August 1996, http://www.ietf.org/rfc/rfc1991.txt Network Working Group, Request for Comments: 2015 - MIME Security with Pretty Good Privacy (PGP), M. Elkins, October 1996, http://www.ietf.org/rfc/rfc2015.txt

本発明は、上記課題を解決するために成されたものであり、メールクライアントが電子メールの暗号化機能を持たない場合でも、電子メールを暗号化して所望の宛先に送信することを可能としつつ、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて電子メールの暗号化及びその送信について臨機応変な対応を行うことができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。

また、携帯端末のような資源の限られたメールクライアントからでも安全に電子メールを暗号化して送信することができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。

さらに、メールクライアントが電子メールの署名検証機能を持たない場合でも、受信された電子メールの電子署名を検証させ該署名検証結果を確認可能としたメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。

本発明に係るメールサーバーは、管理すべき宛先への電子メールを受信蓄積し、メールクライアントからの要求により蓄積した電子メールをメールクライアントへ送信するメールサーバーにおいて、受信した電子メールに電子署名がなされているか否かを判定する署名判定手段と、電子メールの署名者の公開鍵を取得する公開鍵取得手段と、前記署名判定手段により電子署名がなされていると判定された場合に、前記公開鍵取得手段が取得した署名者の公開鍵を使って電子署名の検証を行う署名検証手段と、前記署名検証手段による電子署名の検証結果を送信する署名検証結果送信手段と、を有することを特徴とする。

このメールサーバーにおいて、電子メールが受信されると、まず、署名判定手段が、受信された電子メールに電子署名がなされているか否かを判定し、電子署名がなされている場合には、公開鍵取得手段が署名者の公開鍵を取得し、署名検証手段がその公開鍵を使って電子メールの電子署名を検証する。そして、署名検証結果送信手段が、電子署名の検証結果を送信する。

このとき、署名検証結果送信手段は、例えば、メールクライアントからの問合せに対して電子署名の検証結果を当該メールクライアントに送信してもよいし、受信メールに電子署名の検証結果を挿入することで当該検証結果をメールクライアントに送信してもよい。

これにより、メールクライアントが電子メールの署名検証機能を有していない場合でも、署名の有効性を確認することが可能となる。また、電子署名の検証に必要となる署名者の公開鍵取得は、メールサーバー側で行われるので、メールクライアントは、鍵取得や有効性検証に関わる煩雑な処理を行わずに済み、メールクライアントの処理負担が軽減される。

また、本発明に係るメールサーバーは、電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答する第２の応答手段をさらに有することを特徴とする。即ち、この第２の応答手段が、電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答するので、メールクライアントは、メールサーバーが電子メールの署名検証機能を有するか否かについて確認することが可能となる。これにより、電子メールの署名検証機能がメールサーバーにある場合にのみ、メールサーバー側の署名検証結果を確認するように対応することができる。

本発明に係るメールクライアントは、メールサーバーに受信蓄積された宛先情報付きの電子メールを当該宛先情報に基づいて受信するメールクライアントにおいて、前記メールサーバーに対して電子メールの署名検証結果を問い合わせる署名検証結果問合せ手段を有することを特徴とする。即ち、この署名検証結果問合せ手段が、メールサーバーに対して電子メールの署名検証結果を問い合わせるので、メールクライアントが電子メールの署名検証機能を有していない場合でも、電子署名の有効性を確認することが可能となる。また、電子署名の検証に必要となる署名者の公開鍵取得は、メールサーバー側で行われるので、メールクライアントは、鍵取得や有効性検証に関わる煩雑な処理を行わずに済み、メールクライアントの処理負担が軽減される。

また、本発明に係るメールクライアントは、メールサーバーに対して電子メールの署名検証機能に関する問合せを行う機能問合せ手段をさらに有し、前記署名検証結果問合せ手段は、前記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、前記メールサーバーに対して電子メールの署名検証結果を問い合わせることを特徴とする。即ち、機能問合せ手段がメールサーバーに対して電子メールの署名検証機能に関する問合せを行い、前記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、署名検証結果問合せ手段がメールサーバーに対して電子メールの署名検証結果を問い合わせるので、メールサーバーが署名検証機能を有していないにもかかわらず、署名検証結果の問合せを毎回行って不必要な通信負荷が発生してしまうといった不都合を防止することができる。

本発明に係る電子メールシステムは、宛先情報付きの電子メールを当該宛先情報に基づいて受信するメールクライアントと、前記電子メールを受信蓄積し前記メールクライアントからの要求により蓄積された電子メールを前記メールクライアントへ送信するメールサーバーとを含んで構成された電子メールシステムにおいて、前記メールクライアントが、前記メールサーバーに対して電子メールの署名検証結果を問い合わせる署名検証結果問合せ手段を有し、前記メールサーバーが、受信した電子メールに電子署名がなされているか否かを判定する署名判定手段と、電子メールの署名者の公開鍵を取得する公開鍵取得手段と、前記署名判定手段により電子署名がなされていると判定された場合に、前記公開鍵取得手段が取得した署名者の公開鍵を使って電子署名の検証を行う署名検証手段と、前記署名検証手段による電子署名の検証結果を送信する署名検証結果送信手段と、を有することを特徴とする。

この電子メールシステムでは、メールサーバーが、宛先情報付きの電子メールを受信蓄積し、メールクライアントからの要求により、蓄積された電子メールをメールクライアントへ送信するが、このメールサーバーにおいて、署名判定手段が受信された電子メールに電子署名がなされているか否かを判定し、公開鍵取得手段が電子メールの署名者の公開鍵を取得する。ここで、署名判定手段により電子署名がなされていると判定された場合、署名検証手段は、公開鍵取得手段が取得した署名者の公開鍵を使って電子署名の検証を行う。

そして、メールクライアントの署名検証結果問合せ手段がメールサーバーに対して電子メールの署名検証結果を問い合わせると、メールサーバーの署名検証結果送信手段が、署名検証手段による電子署名の検証結果を送信するので、メールクライアントが電子メールの署名検証機能を有していない場合でも、電子署名の有効性を確認することが可能となる。また、電子署名の検証に必要となる署名者の公開鍵取得は、メールサーバー側で行われるので、メールクライアントは、鍵取得や有効性検証に関わる煩雑な処理を行わずに済み、メールクライアントの処理負担が軽減される。

また、本発明に係る電子メールシステムでは、前記メールクライアントが、メールサーバーに対して電子メールの署名検証機能に関する問合せを行う機能問合せ手段をさらに有し、前記署名検証結果問合せ手段は、前記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、前記メールサーバーに対して電子メールの署名検証結果を問い合わせることを特徴とし、前記メールサーバーが、電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答する第２の応答手段をさらに有することを特徴とする。

この電子メールシステムでは、メールクライアントの機能問合せ手段がメールサーバーに対して電子メールの署名検証機能に関する問合せを行うと、メールサーバーの第２の応答手段が、電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答する。この応答を受けたメールクライアントでは、署名検証結果問合せ手段は、上記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、メールサーバーに対して電子メールの署名検証結果を問い合わせるので、メールサーバーが署名検証機能を有していないにもかかわらず、署名検証結果の問合せを毎回行って不必要な通信負荷が発生してしまうといった不都合を防止することができる。

以上説明したように、本発明のメールサーバーは、受信した電子メールに電子署名がなされている場合に、電子署名の検証を行ない、その検証結果をメールクライアントに通知するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果を確認することが可能となる。また、電子メールの署名検証に必要となる署名者の公開鍵の管理や有効性検証など煩雑な処理をメールクライアントではなく、メールサーバーで行なうので、携帯端末のような資源の限られたメールクライアントでも安全に電子メールの署名検証結果を確認することが可能となる。

また、本発明のメールクライアントは、メールサーバーが電子メールの署名検証機能を持つかどうか問い合わせ、メールサーバーで電子メールの署名検証が可能な場合には、メールサーバーに電子メールの署名検証結果を送信するよう指示したり、あるいは、取得した電子メールに挿入されている署名検証結果を識別判断するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果の確認が可能となる。

［第１実施形態］
以下、本発明の第１実施形態について、図面を参照しながら詳細に説明する。

図１には、第１実施形態のメールサーバー１０とメールクライアント３０の機能ブロック及びネットワーク構成を示している。

ネットワーク５０には、メールを作成し送信するメールクライアント３０と、メールクライアント３０がメールの送信を依頼するメールサーバー１０と、メールの宛先の公開鍵を保持する公開鍵サーバー５１とが接続されている。

［第１実施形態のメールサーバー１０の構成］
先ず、メールサーバー１０の機能ブロックについて説明する。図１に示すように、メールサーバー１０は、ネットワーク通信部１１、電子メール送信依頼受信部１２、暗号化指示受信部１３、公開鍵取得部１４、公開鍵エラー通知部１５、宛先除外部１６、公開鍵有効性検証部１７、機能問合せ応答部１８、電子メール送信部１９、及びメール暗号化部２０を含んで構成される。以下、各機能ブロックを順に説明する。

ネットワーク通信部１１は、ネットワーク５０と接続して、メールクライアント３０や公開鍵サーバー５１と通信を行う部分である。メールクライアント３０から送信される電子メールの送信依頼の受信、メールクライアント３０から送信される暗号化指示の受信や、メールクライアント３０から送信される暗号化機能の問合せ要求の受信と応答の送信、宛先の公開鍵の取得エラーや公開鍵の無効エラーの通知送信、宛先への電子メールの送信、公開鍵取得のための公開鍵サーバー５１との通信などを行う。

電子メール送信依頼受信部１２は、メールクライアント３０から、電子メールデータや宛先情報を含む電子メール送信依頼を受信する。メールクライアント３０が、ＳＭＴＰで送信を行う場合には、ＤＡＴＡコマンドやＲＣＰＴコマンドにより電子メールデータと宛先情報が受信される。また、メールサーバー１０がＨＴＴＰサーバーの機能を有しＷＥＢサーバーとなっている場合には、メールクライアント３０のＷＥＢブラウザから、ＨＴＴＰのＰＯＳＴメソッドにより、電子メールデータと宛先情報を含む送信依頼要求が受信される。

暗号化指示受信部１３は、電子メール送信依頼受信部１２が受信した電子メールデータをメールサーバー１０で暗号化する旨の指示をメールクライアント３０から受信する部分である。暗号化指示は、メールクライアント３０からＳＭＴＰの拡張コマンドあるいはＨＴＴＰのＰＯＳＴメソッドにより送信されるデータにより指示される。

公開鍵取得部１４は、暗号化指示受信部１３が電子メールの暗号化指示を受信した場合に、メールサーバー１０で電子メールを宛先ごとに暗号化するための公開鍵を取得する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得される。もちろん、本発明は、本実施形態に限定されるわけでなく、公開鍵の取得を、例えば、メールサーバー１０に予め公開鍵を格納してき、その公開鍵レポジトリ（図示せず）から取得するようにしてもよい。

公開鍵エラー通知部１５は、公開鍵取得部１４が公開鍵を取得できなかった場合、あるいは、公開鍵有効性検証部１７により、取得した公開鍵が無効であると判定された場合に、電子メールの暗号化ができない宛先についてメールクライアント３０に通知を行う部分である。通知は、電子メールによりＳＭＴＰでメールクライアント３０に通知するか、あるいは、メールクライアント３０のＷＥＢブラウザからのＨＴＴＰのＧＥＴメソッドあるいはＰＯＳＴメソッドの応答として通知する。

宛先除外部１６は、公開鍵取得部１４が公開鍵を取得できなかった宛先、あるいは、公開鍵有効性検証部１７により公開鍵が無効であると判定された宛先が、存在する場合に、電子メール送信依頼受信部１２がメールクライアント３０から送信依頼された宛先情報の宛先から、電子メールの暗号化できない宛先のみを除外した宛先情報を生成する部分である。

公開鍵有効性検証部１７は、公開鍵取得部１４が取得した公開鍵の有効性を検証する部分である。公開鍵の有効性は、公開鍵の有効期限が切れていないか、公開鍵の廃棄要求が認証局より発効されていないか、あるいは、公開鍵の証明書の認証局の署名が正しいかなどにより検証される。

機能問合せ応答部１８は、メールクライアント３０から送信された、メールサーバー１０の電子メールの暗号化機能に関する問合せを受信し、これに対する応答を送信する部分である。

電子メール送信部１９は、電子メール送信依頼受信部１２が、メールクライアント３０から受信した電子メールデータと宛先情報に従って、電子メールを宛先情報の各宛先に対して送信する部分である。宛先のアドレス情報に応じて、最適なメール転送サーバーに電子メールデータを送信する。また、暗号化指示受信部１３が、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、メール暗号化部２０で暗号化した電子メールを各宛先に対して送信する。

メール暗号化部２０は、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、公開鍵取得部１４が取得した宛先の公開鍵を使って、電子メールデータを暗号化する部分である。

［第１実施形態のメールクライアント３０の構成］
次に、メールクライアント３０の機能ブロックについて説明する。図１に示すように、メールクライアント３０は、操作表示部３１、電子メール生成部３２、電子メール送信依頼部３３、公開鍵取得検証部３４、メール暗号化部３５、宛先再設定部３６、通知受信部３７、暗号化指示部３８、機能問合せ部３９、及びネットワーク通信部４０を含んで構成される。以下、各機能ブロックを順に説明する。

操作表示部３１は、操作画面の表示や暗号化送信エラー時の表示、ユーザーが送信すべき電子メールの内容や宛先の入力、送信する電子メールの暗号化指示や、電子メールの送信指示などを行う部分である。

電子メール生成部３２は、操作表示部３１からユーザーが入力した電子メールの内容や宛先情報からメールサーバー１０に送信可能な形態の電子メールデータを生成する部分である。メールサーバー１０にＳＭＴＰで送信依頼を行なう場合には、ＩＥＴＦのＲＦＣ８２２で規定された電子メールフォーマットのデータを生成する。また、メールサーバー１０にＨＴＴＰで送信依頼を行なう場合には、メールサーバー１０にＰＯＳＴメソッドで、メールサーバー１０で決められたフォーマットのデータを生成する。

電子メール送信依頼部３３は、電子メール生成部３２が生成した電子メールデータをネットワーク通信部４０を介してメールサーバーに送信依頼する部分である。メールサーバー１０への電子メールを送信依頼する方法としては、ＳＭＴＰを利用する方法と、ＨＴＴＰを利用する方法がある。

公開鍵取得検証部３４は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に必要となる宛先の公開鍵を取得しその有効性を検証する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得しその有効性を検証する。もちろん、本発明は本実施形態に限定されるわけでなく、公開鍵の取得を、ネットワーク上の公開鍵サーバー５１からでなく、メールクライアント３０に予め格納しておいた公開鍵レポジトリ（図示せず）から取得するようにしてもよい。

メール暗号化部３５は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に、公開鍵取得検証部３４が取得し有効性を検証した宛先の公開鍵を使って、電子メール生成部３２が生成した電子メールの暗号化を行う部分である。

宛先再設定部３６は、通知受信部３７が受信したメールサーバー１０からの電子メールの暗号化ができない宛先の通知情報を基に、操作表示部３１でユーザーが入力した宛先情報の宛先から電子メールの暗号化が不可能な宛先を除外した宛先に宛先情報を再設定する部分である。

通知受信部３７は、メールサーバー１０から通知されるメールサーバー１０で電子メールの暗号化ができない宛先の通知情報を受信する部分である。

暗号化指示部３８は、メールサーバー１０に対して、電子メール送信依頼部３３が送信依頼した電子メールを暗号化するようにメールサーバー１０へ指示する部分である。

機能問合せ部３９は、メールサーバー１０にメールサーバー１０が電子メールの暗号化機能を有するか問い合わせて、メールサーバー１０から暗号化機能の能力情報を受信する部分である。

ネットワーク通信部４０は、ネットワーク５０と接続して、メールサーバー１０や公開鍵サーバー５１と通信を行う部分である。メールサーバー１０への電子メールの送信依頼の送信や、メールサーバー１０への電子メールの暗号化指示の送信、メールサーバー１０への暗号化機能の問合せ要求の送信と応答の受信、宛先の公開鍵の取得エラーや無効通知の受信、公開鍵の取得のための公開鍵サーバー５１との通信などを行う。

［第１実施形態のメールサーバー１０による電子メールの送信処理］
次に、メールサーバー１０による電子メールの送信処理のフローを、図２に沿って説明する。

メールサーバー１０は、電子メール送信依頼受信部１２で、メールクライアント３０から電子メールの送信依頼を受信すると、まずステップＳ１０で、暗号化指示受信部１３により、電子メールの暗号化が指示されているかどうかをチェックする。電子メールの送信依頼は、メールクライアント３０との通信がＳＭＴＰであれば、ＤＡＴＡコマンドによる電子メールデータとＲＣＰＴコマンドによる宛先情報の送信により行われる。また、メールクライアント３０との通信がＨＴＴＰであれば、例えば、ＰＯＳＴメソッドにより送信される入力要素データ名”cont=”の値として送信される電子メールデータと、入力要素データ名”to=”の値として送信される宛先情報により送信される。

ＳＭＴＰ通信の場合、暗号化指示は、ＤＡＴＡコマンドを拡張して新たに定義するＥＤＡＴＡコマンドにより行う。メールクライアント３０からの電子メールの送信依頼を、ＤＡＴＡコマンドでなくＥＤＡＴＡコマンドで受信した場合には、受信した電子メールデータを、ＲＣＰＴコマンドで受信した宛先に、その宛先の公開鍵を使って暗号化して送信することを示す。また、例えば、暗号化指示をＳＭＴＰの拡張コマンドＥＤＡＴＡではなく、通常のＤＡＴＡコマンドで受信する電子メールデータのメールヘッダにフィールド名“X-Encrypt”からなるフィールドを設定することで行うこともできる。

また、ＨＴＴＰ通信の場合には、暗号化指示は、ラジオボタン選択型の入力要素データ名”encrypt＝“の値として指示する。

ステップＳ１０で、暗号化指示が検知されない場合には、ステップＳ２４に進み、送信依頼された電子メールをＳＭＴＰで宛先情報の宛先に送信する。

一方、ステップＳ１０で、暗号化指示が検知された場合には、ステップＳ１１に進み、公開鍵取得部１４が、電子メール送信依頼受信部１２で受信した宛先情報の宛先の公開鍵の取得を行う。ここでの公開鍵の取得は、公開鍵サーバー５１に宛先のメールアドレスに対応する公開鍵を問合せて取得することで行う。あるいは、例えば、予め宛先の公開鍵をメールサーバー１０の公開鍵レポジトリ（図示せず）に格納しておき、そこから取得するようにしてもよい。

次に、ステップＳ１２で、ステップＳ１１での公開鍵の取得処理において全ての公開鍵が取得できたかどうかを判定する。ここで、電子メールの暗号化においては、宛先の公開鍵がないとその宛先には電子メールを暗号化して送信することはできないので、電子メールの暗号化ができない宛先が存在しないかをここでチェックする。

宛先情報の全ての宛先の公開鍵が取得できた場合には、ステップＳ１７に進み、１つでも公開鍵の取得ができなかった宛先が存在した場合には、ステップＳ１３に進む。

ステップＳ１７では、公開鍵有効性検証部１７により、ステップＳ１２で取得された公開鍵の有効性を検証する。ここでの有効性の検証は、公開鍵になされている電子署名が正しいか否か、公開鍵の有効期限が切れているか否か、および、公開鍵が廃棄されているか否かをチェックすることで行う。なお、公開鍵がＸ．５０９の公開鍵基盤により公開鍵証明書として認証局から発行されている場合には、その公開鍵証明書が認証局しから発行されている証明書廃棄リストに登録されていないかを確認することで廃棄の有無をチェックする。

次のステップＳ１８では、ステップＳ１７での公開鍵の有効性検証処理で、全ての宛先の公開鍵が有効であったかどうかを判定する。ここで、電子メールの暗号化においては、宛先の公開鍵が有効でない場合には、その宛先には電子メールを暗号化して送信することはできないので、電子メールの暗号化ができない宛先が存在するかをここでチェックする。

全ての宛先の公開鍵が有効であった場合には、ステップＳ２３に進み、１つでも公開鍵が有効でなかった宛先が存在した場合には、後述するステップＳ１９に進む。

ステップＳ２３では、メール暗号部２０により、宛先の公開鍵を使って電子メールを暗号化し、ステップＳ２４で、宛先情報の宛先に暗号化した電子メールをＳＭＴＰで送信し、処理を終了する。

前述したステップＳ１２で、公開鍵の取得ができなかった宛先が１つ以上存在したと判定された場合の処理について説明する。この場合には、まずステップＳ１３で、メールサーバー１０が宛先除外モードに設定されているかどうかを判定する。宛先除外モードの設定は、メールサーバーの管理者が予め設定しておく。また、宛先除外モードを、メールサーバー１０に予め設定しておくのではなく、メールクライアント３０から、電子メールの送信依頼時に設定するようにしてもよい。

宛先除外モードに設定されている場合には、ステップＳ１４に進み、宛先除外部１６が、宛先情報に含まれる宛先から、公開鍵の取得できなかった宛先を除外し、ステップＳ１５に進む。ステップＳ１５では、公開鍵エラー通知部１５が、除外した宛先のリストをメールクライアント３０に通知し、ステップＳ１７に進み、取得した公開鍵の有効性検証に進む。

一方、ステップＳ１３で宛先除外モードに設定されていない場合には、ステップＳ１６に進み、公開鍵エラー通知部１５が、公開鍵が取得できない宛先が存在するために、メールクライアント３０から指示された宛先に電子メールの暗号化を行って送信することができない旨のエラーをメールクライアント３０に通知し、処理を終了する。

前述したステップＳ１８で、公開鍵が有効でない宛先が１つ以上存在したと判定された場合の処理について説明する。この場合には、まずステップＳ１９で、メールサーバー１０が宛先除外モードに設定されているかどうかを判定する。

宛先除外モードに設定されている場合には、ステップＳ２０に進み、宛先除外部１６が、宛先情報に含まれる宛先から、公開鍵が無効であった宛先を除外し、ステップＳ２１に進む。ステップＳ２１では、公開鍵エラー通知部１５が、除外した宛先のリストをメールクライアント３０に通知し、ステップＳ２３に進み、電子メールの暗号化処理へ進む。

一方、ステップＳ１９で宛先除外モードに設定されていない場合には、ステップＳ２２に進み、公開鍵エラー通知部１５が、公開鍵が無効である宛先が存在するために、メールクライアント３０から指示された宛先に電子メールの暗号化を行って送信することができない旨のエラーをメールクライアント３０に通知し、処理を終了する。

以上説明したように、第１実施形態のメールサーバー１０は、メールクライアント３０から電子メールの送信依頼がなされ、かつ、暗号化指示が行なわれた場合に、メールサーバー１０で、送信依頼された電子メールを暗号化して、宛先に送信するので、電子メールの暗号化機能を有していない携帯端末のようなメールクライアントでも、暗号メールを送信することが可能となる。また、電子メールの暗号化に必要となる、宛先の公開鍵の取得や有効性検証といった煩雑な処理を、メールクライアントではなくメールサーバで行なうようにすることができる。

［第１実施形態のメールクライアント３０による電子メールの送信処理］
次に、メールクライアント３０による電子メールの送信処理フローを、図３に沿って説明する。

ユーザーは、メールクライアント３０の操作表示部３１から、メールの作成送信操作や暗号化指示を行なう。ここで、メールクライアント３０は、例えば、メールクライアントの起動時に、予め、機能問合せ部３９がメールサーバー１０に電子メールの暗号化機能の能力を問合せるものとする。メールサーバー１０が電子メールの暗号化機能を有すると判断された場合、あるいは、メールサーバー１０が暗号化機能を有していなくとも、メールクライアント３０に電子メールの暗号化機能が備わっている場合には、電子メールの暗号化を選択するメニューが操作表示部３１に表示され、そうでない場合には表示されないようになっている。

機能問合せ部３９の問合せに対して、メールサーバー１０の機能問合せ応答部１８がその暗号化機能の能力について応答する。

ユーザーが操作表示部３１からメールの作成送信指示を行ない電子メール生成部３２が、電子メールデータと宛先情報を生成すると、まず、図３のステップＳ３０で、ユーザーがメールの暗号化を指定したかどうか判定する。

ステップＳ３０で、ユーザーが電子メールの暗号化を指示したと判断された場合には、ステップＳ３１に進み、そうでない場合には、ステップＳ３９に進んでメールサーバー１０に電子メールの送信依頼を行う。

ステップＳ３１では、機能問合せ部３９が、メールサーバー１０に電子メールの暗号化機能について問合せる。メールサーバー１０の暗号化機能ついては、メールクライアント３０の起動時に問い合わせされているが、ここで、電子メールをメールサーバー１０に送信依頼する前に、毎回、メールサーバー１０の暗号化機能について問合せを行なうのは、サーバー管理者がメールサーバー１０の暗号化機能を一時的に停止するなどして、一時的に使用できない場合にも適切に対応可能とするためである。

次のステップＳ３２では、ステップＳ３１で問い合わせたメールサーバー１０の電子メールの暗号化機能が利用可能であるかどうか判断する。メールサーバー１０の暗号化機能が利用可能であると判断された場合には、ステップＳ３３に進み、そうでない場合には、ステップＳ３４に進む。

ステップＳ３３では、暗号化指示部３８が、暗号化指示を設定する。暗号化指示の方法は、前述したように、電子メールのメールヘッダの暗号化指示を示すフィールド名”X-Encrypt”のフィールドを設定するか、ＳＭＴＰコマンドの拡張コマンド(ＥＤＡＴＡ)を送信するか、あるいは、ＨＴＴＰのＰＯＳＴメソッドのラジオボタン選択型の入力要素データ名”encrypt＝“の値として送信する。

次のステップＳ３９では、電子メール送信依頼部３３が、電子メール生成部３２が生成した電子メールデータと宛先情報からなる送信依頼をメールサーバー１０に送信する。例えば、暗号化指示をＳＭＴＰの拡張コマンド(ＥＤＡＴＡ)として送信する場合には、これから送信する電子メールデータをメールサーバー１０で暗号化して宛先に送信する旨の依頼を示すＥＤＡＴＡコマンドと、宛先情報を指示するＲＣＰＴコマンドにより送信される。また、例えば、暗号化指示を電子メールのメールヘッダの拡張フィールド(X-Encrypt)として指示する場合には、電子メールデータを宛先に送信する旨の依頼を示す通常のＤＡＴＡコマンドと、宛先情報を指示するＲＣＰＴコマンドを送信する。また、例えば、暗号化指示がＨＴＴＰのＰＯＳＴメソッドのラジオボタン選択型の入力要素データ名”encrypt＝“として指示する場合には、電子メールデータと宛先情報の入力要素データと一緒にメールサーバー１０に送信する。

次のステップＳ４０では、ステップＳ３９でメールサーバー１０に行った電子メールの送信依頼に対して、通知受信部３７がエラー通知を受信していないか判定する。エラーが発生していなければ、電子メールの送信処理を終了し、そうでない場合には、ステップＳ４１に進む。

ステップＳ４１では、公開鍵の取得エラーあるいは公開鍵の無効エラーによりメールサーバー１０から通知され電子メールを暗号化できない宛先があると判断された場合に、これを操作表示部に表示するとともに、宛先再設定部３６が、電子メールを暗号化可能な宛先のみに再設定し、ステップＳ３３に戻って、再度、電子メールの暗号化送信処理を行う。

一方、ステップＳ３２でメールサーバー１０に暗号化機能が利用可能でないと判断された場合には、ステップＳ３４へ進み、自装置に暗号化機能が備わっているかどうかを判定する。暗号化機能が備わっている場合には、ステップＳ３５に進み、そうでない場合には、ステップＳ３８で、電子メールを暗号化して送信できない旨の警告を操作表示３１に表示して、処理を終了する。

ステップＳ３５では、公開鍵取得検証部３４が、宛先の公開鍵を公開鍵サーバー５１から取得し、有効性を検証する。次のステップＳ３６では、全ての宛先の公開鍵が取得でき、かつ、有効であるか判断する。ここで、公開鍵が取得できないか、あるいは、公開鍵が無効な宛先が１つ以上存在した場合には、ステップＳ３８に進んで、電子メールを暗号化して送信できない旨の警告を操作表示３１に表示して、処理を終了する。

一方、ステップＳ３６で全ての公開鍵が取得できかつ有効であった場合には、ステップＳ３７に進み、メール暗号化部３５が電子メールを暗号化して、ステップＳ３９に進み、暗号化された電子メールデータと宛先をメールサーバー１０に送信する。

以上説明したように、第１実施形態のメールクライアント３０は、メールサーバー１０が電子メールの暗号化機能を有する場合に、メールサーバーに電子メールの送信依頼をする場合に、メールサーバーで電子メールを暗号化して送信するよう依頼するので、メールクライアントが電子メールの暗号化機能を有していない場合でも、電子メールを暗号化して送信することが可能となる。例えば、メールクライアントがＷＥＢブラウザであり、メール送信プロトコル(ＳＭＴＰ)と異なるプロトコル（ＨＴＴＰ）しか有していない場合にも、メールサーバー１０に電子メールを暗号化するよう指示して電子メールを暗号化して送信することが可能となる。

また、メールクライアントが指示した宛先に、メールサーバーで電子メールを暗号化して送信できない宛先が存在すれば、これを、検知してユーザーに警告したり、あるいは、宛先を再設定して送信することが可能となる。

［第２実施形態］
以下、本発明の第２実施形態について、図面を参照しながら詳細に説明する。

図４には、第２実施形態のメールサーバー６０とメールクライアント７０の機能ブロック及びネットワーク構成を示している。

ネットワーク８０には、他のメールサーバー（図示せず）あるいは他のメールクライアント(図示せず)から送られてきたメールを受信し蓄積するメールサーバー６０と、メールサーバー６０に接続しユーザー宛ての電子メールを取得閲覧するメールクライアント７０と、メールの送信元の公開鍵を保持する公開鍵サーバー８１とが接続されている。

［第２実施形態のメールサーバー６０の構成］
先ず、メールサーバー６０の機能ブロックについて説明する。図４に示すように、メールサーバー６０は、ネットワーク通信部６１、電子メール受信蓄積部６２、署名検知部６３、公開鍵取得部６４、署名検証結果応答部６５、署名検証部６６、機能問合せ応答部６７、電子メール送信部６８、及び署名検証結果挿入部６９を含んで構成される。以下、各機能ブロックを順に説明する。

ネットワーク通信部６１は、ネットワーク８０と接続して、メールクライアント７０や公開鍵サーバー８１と通信を行う部分である。ネットワーク上に接続する他のメールサーバー(図示せず)や他のメールクライアント（図示せず）から送信転送されてきた電子メールの受信や、メールクライアント７０から送信される署名検証機能の能力問合せの受信と応答の送信、署名検証結果の問合せ要求の受信と応答の送信、メールクライアント７０からの電子メールの取り出し要求の受信とそれに応答する電子メールの送信、公開鍵取得のための公開鍵サーバー８１との通信などを行う。

電子メール受信蓄積部６２は、ネットワークの他のメールサーバー(図示せず)や他のメールクライアント（図示せず）から送信転送されてきた、メールサーバー６０がメールボックスを保持する宛先の電子メールを受信し蓄積する部分である。受信蓄積された電子メールは、メールクライアント７０によりＰＯＰ３(ＰＯＳＴ Office Protocol Version３)やＩＭＡＰ４(Internet Message Access Protocol Version４)により取得閲覧される。また、メールサーバー６０がＨＴＴＰサーバー機能を有しＷＥＢサーバーとなっている場合には、メールクライアント７０上のＷＥＢブラウザ（図示せず）からＨＴＴＰにより、受信した電子メールの取得閲覧が行われる。

署名検知部６３は、電子メール受信蓄積部６２が受信蓄積した電子メールに送信者の電子署名がなされているかどうかを検知する部分である。

公開鍵取得部６４は、署名の検証に必要となる署名者の公開鍵を取得する部分である。公開鍵は、ネットワーク８０に接続する公開鍵サーバー８１から取得される。もちろん、公開鍵の取得は、これに限定されるわけでなく、例えば、メールサーバー６０に予め公開鍵を格納しておいた公開鍵レポジトリ（図示せず）から取得するようにしてもよい。

署名検証部６５は、署名検知部６３が受信電子メールが送信者の電子署名がなされていると判断した場合に、公開鍵取得部６４が取得した公開鍵を使ってその署名検証を行なう部分である。署名検証は、署名のダイジェスト値の正当性だけでなく、使用する電子メールの署名者の公開鍵の有効性（有効期限切れや廃棄要求が出ていないかのチェック）も判断して行なう。

署名検証結果応答部６６は、メールクライアント７０から、電子メールに対する署名検証結果の問合せがあった場合に、署名検証部６５が行なった電子メールの署名検証結果をメールクライアント７０に応答する部分である。

機能問合せ応答部６７は、メールクライアント７０からメールサーバー６０に電子メールの署名検証機能についての能力問合せが合った場合に、その能力情報をメールクライアント７０に応答する部分である。

電子メール送信部６８は、メールクライアント７０からＰＯＰ３やＩＭＡＰ４などのプロトコルで電子メールの取り出し要求を受けた場合に、電子メール受信蓄積部６２が受信蓄積している電子メールをメールクライアント７０に送信する部分である。

署名検証結果挿入部６９は、署名検証部６５が署名検証した結果を、電子メール受信蓄積部６２が受信蓄積している電子メールのメールヘッダに挿入する部分である。署名検証結果は、例えば、”X-Signature-Verify“というフィールド名とそれに続く署名検証結果からなるフィールドを挿入することで行われる。電子メールのメールヘッダは、電子署名のダイジェスト計算に使用されない部分であるので、署名検証結果のフィールドをメールヘッダに追加しても、ダイジェスト値（つまりは、署名値）が変わってしまうことはない。

なお、本実施形態では、説明のために、メールサーバー６０に署名検証結果応答部６７と署名検証結果挿入部６９の両方を備えるようにしたが、もちろん、本発明はそれに限定されるわけでなく、どちらか一方のみを実装するようにしても良い。

［第２実施形態のメールクライアント７０の構成］
次に、メールクライアント７０の機能ブロックについて説明する。図４に示すように、メールクライアント７０は、操作表示部７１、電子メール取得部７２、署名検証結果問合せ部７３、機能問合せ部７４、及びネットワーク通信部７５を含んで構成される。以下、各機能ブロックを順に説明する。

操作表示部７１は、操作画面の表示やユーザーが電子メールの取得閲覧を指示したり、メールサーバー６０から取得した電子メールやその署名検証結果の表示などを行う部分である。

電子メール取得部７２は、操作表示部７１からユーザが電子メールの取得閲覧を指示した場合に、メールサーバー６０に受信蓄積されている電子メールを、ＰＯＰ３やＩＭＡＰ４などのプロトコルによりメールサーバー６０から取得する部分である。

署名検証結果問合せ部７３は、メールサーバー６０から取得した電子メールの署名検証結果について問い合わせる部分である。

機能問合せ部７４は、メールサーバー６０が署名検証機能を有するかどうかについてその能力問合せをメールサーバー６０に行なう部分である。

ネットワーク通信部７５は、ネットワーク８０と接続して、メールサーバー６０と通信を行う部分である。メールサーバー６０への電子メールの取得要求の送信や応答としての電子メールの受信、メールサーバー６０への署名検証機能の問合せ要求の送信と応答の受信、電子メールの署名検証結果の問合せ要求の送信と応答の受信などを行う。

［第２実施形態のメールサーバー６０による電子メールの受信処理］
次に、メールサーバー６０による電子メールの受信処理のフローを、図５に沿って説明する。

メールサーバー６０は、電子メール受信蓄積部６２が、ネットワーク８０に接続する他のメールサーバー(図示せず)や他のメールクライアント(図示せず)から管理するメールボックスの宛先の電子メールを受信し蓄積すると、先ず、ステップＳ５０で、署名検知部６３が、電子メール電子署名がなされているかどうか判定する。電子署名がなされていれば、ステップＳ５１へ進み、そうでなければ、ステップＳ５５に進む。

ステップＳ５１では、公開鍵取得部６４が、電子メールになされている電子署名の検証に必要となる署名者（通常は、電子メールの送信者である）の公開鍵を取得する。

次のステップＳ５２では、署名検証部６５が、電子メールになされている電子署名の検証を行なう。電子署名の検証は、電子メールのダイジェスト値の正当性に加えて、ステップＳ５１で取得した署名者の公開鍵の有効性検証を含むものとする。署名者の公開鍵の有効期限が切れていたり、あるいは、公開鍵の廃棄要求が発行されている場合には、公開鍵が無効であるため、電子署名の正当性が保証できず、無効な電子署名と判断される。

次のステップＳ５３では、署名検証結果を電子メールのメールヘッダに挿入するモードであるかどうか判定する。このモードの設定は、メールサーバー６０の管理者が予め設定しておく。署名検証結果を電子メールのメールヘッダに挿入するモードであれば、ステップＳ５４に進み、署名検証結果をメールヘッダに挿入する。また、そうでない場合には、ステップＳ５７に進み、メールクライアント７０から電子メール受信蓄積部６２が受信蓄積している電子メールの取出し要求があるまで待機を行なう。

ステップＳ５４では、署名検証結果挿入部６９が、ステップＳ５２での検証した電子メールの署名検証結果を、電子メール受信蓄積部６２が蓄積している電子メールのメールヘッダに挿入する。挿入される署名検証結果は、例えば、”X-Signature-Verify:”というフィールド名とそれに続くフィールド値により構成される。フィールド値には、検証結果を示す文字列が設定される。署名が有効であれば“OK”という文字列が設定され、無効である場合には”NG”という文字列とそれに続いて理由が設定される。例えば、署名者の公開鍵の有効期限が切れているために署名が無効と検証された場合には、”X-Signature-Verify:NG;reason=ExpiredPublic Key”というフィールドがメールヘッダに挿入されることになる。

ここで、署名検証結果が無効となった場合に、電子メールデータを削除するように、メールサーバー６０が設定されていた場合には、メールサーバー６０が電子メール受信蓄積部６２に蓄積された電子メールを自動的に削除するようにすることもできる。

次のステップＳ５５では、電子メール送信部６８が、メールクライアント７０からの、電子メール取出し要求を受信するまで待機を行なう。電子メール取出し要求が受信されると、ステップＳ５６に進み、電子メール送信部６８が、署名検証結果をメールヘッダに挿入した電子メールを、メールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。また、例えば、メールサーバー６０が、ＨＴＴＰサーバーであるＷＥＢサーバー機能を有する場合には、メールクライアント７０のＷＥＢブラウザからの指示により、電子メールの取出し要求としてＨＴＴＰが利用される。この場合、電子メールは、ＨＴＭＬに変換されて送信される。

一方、ステップＳ５３でメールサーバー６０が署名検証結果挿入モードでないと判定された場合、ステップＳ５７へ進み、メールクライアント７０からの電子メール取出し要求があるまで待機する。そして、電子メール取出し要求が受信されると、ステップＳ５８へ進み、電子メール送信部６８が、電子メール受信蓄積部６２により受信蓄積された電子メール（署名検証結果が挿入されていない電子メール）をメールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。

次のステップＳ５９では、署名検証結果応答部６６が、メールクライアント７０から、署名検証結果の問合せ要求があるまで待機を行ない、メールクライアント７０から、署名検証結果の問合せ要求が受信されると、次のステップＳ６０で署名検証結果をメールクライアント７０に応答する。

以上説明したように、第２実施形態のメールサーバー６０は、受信蓄積した電子メールに電子署名がなされている場合に、この電子署名を検証し、その検証結果を、自動的に電子メールに挿入するか、あるいは、メールクライアント７０からの問合せに対して応答するので、電子署名の検証機能を有していない携帯端末のようなメールクライアントでも、電子署名の検証結果を確認することが可能となる。また、署名検証のために必要となる、署名者の公開鍵の取得や有効性検証といった煩雑な処理を、メールクライアントではなくメールサーバで行なうようにすることができる。

［第２実施形態のメールクライアント７０による電子メールの受信処理］
次に、メールクライアント７０による電子メールの取得処理のフローを、図６に沿って説明する。

メールクライアント７０において、ユーザーが操作表示部７１から電子メールの取得を要求すると、先ず、ステップＳ７０で、電子メール取得部７２が、メールサーバー６０に対して、電子メールの取得要求を発行し、その応答として電子メールの受信を行ない、次に、ステップＳ７１で、受信した電子メールのメールヘッダに署名検証結果が挿入されているかどうかをチェックする。署名検証結果の挿入は、電子メールのメールヘッダに”X-Ｓingnature-Verify:”というフィールド名のフィールドが存在するかどうかを判定して行なう。

署名検証結果が電子メールに挿入されていれば、ステップＳ７４に進み、取得した電子メールの内容とその署名検証結果を操作表示部７１に表示する。一方、署名検証結果が電子メールに挿入されていない場合には、ステップＳ７２に進み、メールクライアント７０が署名検証結果問合せモードに設定されているか判定する。

なお、署名検証結果問合せモードの設定は、メールクライアント７０のユーザーが予め設定する。署名検証結果問合せモードをオンに設定した場合には、機能問合せ部７４が、メールサーバー６０に署名検証機能の能力問合せを行ない、メールサーバー７０が署名検証機能を有する場合のみオンに設定できるようになっている。メールサーバー７０が署名検証機能を有しない場合には、署名検証結果問合せモードの設定オフに自動的にリセットされる。

メールクライアント７０が署名検証結果問合せモードに設定されている場合は、ステップＳ７３に進み、署名検証結果問合せ部７３が、メールサーバー６０に、ステップＳ７０で取得した電子メールの署名検証結果を問い合わせる。そして、次のステップＳ７４で、取得した電子メールとその署名検証結果を操作表示部７１に表示して処理を終了する。

一方、ステップＳ７２でメールクライアント７０が、署名検証結果問合せモードに設定されていない場合には、ステップＳ７５へ進み、取得した電子メールを操作表示部７１に表示して処理を終了する。

以上説明したように、第２実施形態のメールクライアント７０は、メールサーバー６０から取得した電子メールに、署名検証結果が挿入されていないか判定し、もし挿入されていれば、電子メールの内容とともにその署名検証結果も表示する。

また、署名検証結果が電子メールに挿入されていない場合には、メールサーバー６０が署名検証機能を持っていれば、メールサーバー６０に対して、取得した電子メールの署名検証結果を問い合わせて、電子メールの内容とともにその署名検証結果も表示するので、メールクライアントが電子メールの署名検証機能を有していない場合でも、電子署名の検証結果を確認することが可能となる。例えば、メールクライアントがＷＥＢブラウザであり、メール取得プロトコルと異なるプロトコルしか有していない場合にも、受信メールの電子署名の検証結果を確認することができる。

本発明の第１実施形態におけるメールサーバー１０とメールクライアント３０の機能ブロック図及びネットワーク構成を示す図である。 本発明の第１実施形態におけるメールサーバー１０による電子メールの暗号化送信のフローチャートである。 本発明の第１実施形態におけるメールクライアント３０による電子メールの送信処理のフローチャートである。 本発明の第２実施形態におけるメールサーバー６０とメールクライアント７０の機能ブロック図及びネットワーク構成を示す図である。 本発明の第２実施形態におけるメールサーバー６０による電子メールの受信処理のフローチャートである。 本発明の第２実施形態におけるメールクライアント７０による電子メールの取得処理のフローチャートである。

符号の説明

１０、６０…メールサーバー、３０、７０…メールクライアント、５０、８０…ネットワーク、５１、８１…公開鍵サーバー、１１、４０、６１、７５…ネットワーク通信部、１２…電子メール送信依頼受信部、１３…暗号化指示受信部、１４、６４…公開鍵取得部、１５…公開鍵エラー通知部、１６…宛先除外部、１７…公開鍵有効性検証部、１８、６７…機能問合せ応答部、１９、６８…電子メール送信部、２０、３５…メール暗号化部、３１、７１…操作表示部、３２…電子メール生成部、３３…電子メール送信依頼部、３４…公開鍵取得検証部、３６…宛先再設定部、３７…通知受信部、３８…暗号化指示部、３９、７４…機能問合せ部、６２…電子メール受信蓄積部、６３…署名検知部、６５…署名検証部、６６…署名検証結果応答部、６９…署名検証結果挿入部、７２…電子メール取得部、７３…署名検証結果問合せ部。

Claims (6)

1. 管理すべき宛先への電子メールを受信蓄積し、メールクライアントからの要求により蓄積した電子メールをメールクライアントへ送信するメールサーバーにおいて、
   受信した電子メールに電子署名がなされているか否かを判定する署名判定手段と、
   電子メールの署名者の公開鍵を取得する公開鍵取得手段と、
   前記署名判定手段により電子署名がなされていると判定された場合に、前記公開鍵取得手段が取得した署名者の公開鍵を使って電子署名の検証を行う署名検証手段と、
   前記署名検証手段による電子署名の検証結果を送信する署名検証結果送信手段と、
   を有するメールサーバー。
2. 電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答する第２の応答手段をさらに有する請求項１記載のメールサーバー。
3. メールサーバーに受信蓄積された宛先情報付きの電子メールを当該宛先情報に基づいて受信するメールクライアントにおいて、
   前記メールサーバーに対して電子メールの署名検証結果を問い合わせる署名検証結果問合せ手段を有するメールクライアント。
4. メールサーバーに対して電子メールの署名検証機能に関する問合せを行う機能問合せ手段をさらに有し、
   前記署名検証結果問合せ手段は、前記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、前記メールサーバーに対して電子メールの署名検証結果を問い合わせることを特徴とする請求項３記載のメールクライアント。
5. 宛先情報付きの電子メールを当該宛先情報に基づいて受信するメールクライアントと、前記電子メールを受信蓄積し前記メールクライアントからの要求により蓄積された電子メールを前記メールクライアントへ送信するメールサーバーとを含んで構成された電子メールシステムにおいて、
   前記メールクライアントが、
   前記メールサーバーに対して電子メールの署名検証結果を問い合わせる署名検証結果問合せ手段を有し、
   前記メールサーバーが、
   受信した電子メールに電子署名がなされているか否かを判定する署名判定手段と、
   電子メールの署名者の公開鍵を取得する公開鍵取得手段と、
   前記署名判定手段により電子署名がなされていると判定された場合に、前記公開鍵取得手段が取得した署名者の公開鍵を使って電子署名の検証を行う署名検証手段と、
   前記署名検証手段による電子署名の検証結果を送信する署名検証結果送信手段と、
   を有することを特徴とする電子メールシステム。
6. 前記メールクライアントが、メールサーバーに対して電子メールの署名検証機能に関する問合せを行う機能問合せ手段をさらに有し、
   前記署名検証結果問合せ手段は、前記機能問合せによりメールサーバーが電子メールの署名検証機能を有すると判明した場合にのみ、前記メールサーバーに対して電子メールの署名検証結果を問い合わせることを特徴とし、
   前記メールサーバーが、電子メールの署名検証機能に関するメールクライアントからの問合せに対して、自機が有する署名検証機能情報を応答する第２の応答手段をさらに有することを特徴とする請求項５記載の電子メールシステム。

Images