JP3840919B2 - メールサーバー、メールクライアント及び電子メールシステム - Google Patents
メールサーバー、メールクライアント及び電子メールシステム Download PDFInfo
- Publication number
- JP3840919B2 JP3840919B2 JP2001168425A JP2001168425A JP3840919B2 JP 3840919 B2 JP3840919 B2 JP 3840919B2 JP 2001168425 A JP2001168425 A JP 2001168425A JP 2001168425 A JP2001168425 A JP 2001168425A JP 3840919 B2 JP3840919 B2 JP 3840919B2
- Authority
- JP
- Japan
- Prior art keywords
- public key
- destination
- server
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、メールサーバー、メールクライアント及び電子メールシステムに係り、より詳しくは、メールクライアントから電子メール及び宛先情報を受信し当該電子メールを宛先情報の宛先に送信するメールサーバー、送信すべき電子メール及び宛先情報をメールサーバーに送信するメールクライアント、及びこれら両者を含んで構成された電子メールシステムに関する。
【０００２】
【従来の技術】
近年、公開鍵暗号技術、共通鍵暗号技術、および、メッセージダイジェスト技術を利用した暗号電子メールが実用されており、この暗号電子メールを利用することで、電子メールの秘匿や改竄防止、送信者認証の機能を実現することが可能となる。
【０００３】
このような暗号電子メールとしては、電子メールのＭＩＭＥ(Multipurpose Internet Mail Extension)機能を利用して暗号電子メールを取り扱えるようにしたＳ／ＭＩＭＥ(Secure MIME)やＰＧＰ／ＭＩＭＥ(Pretty Good Privacy 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（米国Microsoft Corporationの登録商標）がある。
【００１３】
ＷＥＢメールでは、ＷＥＢブラウザで入力した電子メールの内容と宛先指定がＨＴＴＰ(Hyper Text Transfer Protocol)により、ＷＥＢサーバーに送信される。ＷＥＢサーバーでは、ＨＴＴＰで受信した電子メールの内容と宛先情報から電子メールを生成し、ＳＭＴＰ(Simple Mail Transfer Protocol)で宛先に電子メール送信を行なう。
【００１４】
また、メールサーバーに受信した電子メールは、ＷＥＢサーバー上でＨＴＭＬ（Hyper Text Markup Language）に変換されＷＥＢブラウザの要求によりＨＴＴＰで送信される。
【００１５】
従来、このようなＷＥＢメールでは、暗号電子メールの機能をＷＥＢブラウザ自体が備えていないため、暗号電子メールを利用できず、秘匿性の高い内容のメールを暗号送信したり、受信メールの改竄検知を行なうことができなかった。
【００１６】
ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化に、ＳＳＬ(Security Socket Layer)などの通信路暗号技術を利用することが一般的に行われているが、この技術は、ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化であり、送受信される電子メール自体の暗号化ができなかったため、メール転送路上の秘匿の問題を解決できなかった。
【００１７】
【発明が解決しようとする課題】
本発明は、上記課題を解決するために成されたものであり、メールクライアントが電子メールの暗号化機能を持たない場合でも、電子メールを暗号化して所望の宛先に送信することを可能としつつ、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて電子メールの暗号化及びその送信について臨機応変な対応を行うことができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００１８】
また、携帯端末のような資源の限られたメールクライアントからでも安全に電子メールを暗号化して送信することができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００１９】
さらに、メールクライアントが電子メールの署名検証機能を持たない場合でも、受信された電子メールの電子署名を検証させ該署名検証結果を確認可能としたメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００２０】
【課題を解決するための手段】
【００２４】
本発明に係るメールサーバーは、メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有することを特徴とする。
【００２５】
本発明に係るメールサーバーでは、受信手段がメールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信すると、公開鍵取得手段が、受信された宛先情報に含まれた各宛先の公開鍵を取得する。そして、暗号化手段が、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化し、送信手段が暗号化された電子メールを各宛先に送信する。このメールサーバーの特徴として、公開鍵検証手段が取得された公開鍵の有効性を検証し、検証結果通知手段が公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行う。即ち、検証結果通知手段は、公開鍵検証手段による公開鍵の有効性の検証結果いかんにかかわらず、その検証結果をメールクライアントへ通知してもよいし、公開鍵が無効であった宛先が存在する場合にのみ、公開鍵が無効であった旨をメールクライアントへ通知してもよい。
【００２６】
これにより、通知を受けたメールクライアントは、公開鍵の有効性の検証結果を確認でき、電子メールを暗号化して送信できない宛先について認知することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００２７】
また、本発明に係るメールサーバーは、上記のメールサーバーにおいて、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有することを特徴とする。この第２の抑止手段によって、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信が抑止されるので、他人に露呈したり有効期限切れとなって無効となってしまった公開鍵を使って暗号化された電子メールが宛先に送信されてしまい電子メールの内容が盗聴あるいは露呈してしまう危険を防止することができる。
【００３３】
本発明に係るメールクライアントは、送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、を有し、前記送信手段は、前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、自機の暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信することを特徴とする。
【００３４】
このメールクライアントは、上記公開鍵取得手段と公開鍵検証手段と暗号化手段とを備えており、問合せ手段による問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明すると、メールクライアントが備えた公開鍵取得手段により宛先の公開鍵を取得し、公開鍵検証手段により前記公開鍵取得手段が取得した公開鍵の有効性を検証する。そして、暗号化手段が前記公開鍵有効性検証手段により有効であると判定された宛先の公開鍵を使って電子メールを暗号化してメールサーバーに送信する。このため、暗号化機能を有するメールサーバーに接続できない環境では、メールクライアント側で電子メールを暗号化して送信するよう切り替えることが可能となる。
【００３７】
また、本発明に係るメールクライアントは、送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、を有することを特徴とする。このメールクライアントでは、検証結果受信手段が、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信すると、第２の宛先再設定手段が、受信された検証結果情報に基づいて宛先を再設定するので、電子メールの暗号化送信が可能な宛先へのみ、電子メールを暗号化して送信するようメールサーバーに指示できるようになる。
【００５０】
本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有し、前記メールクライアントが、前記検証結果通知手段による通知を受信する検証結果受信手段を有することを特徴とする。
【００５１】
この電子メールシステムでは、メールサーバーの受信手段がメールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信すると、公開鍵取得手段が、受信された宛先情報に含まれた各宛先の公開鍵を取得する。そして、暗号化手段が、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化し、送信手段が暗号化された電子メールを各宛先に送信する。この請求項１７記載の電子メールシステムの特徴として、メールサーバーにて、公開鍵検証手段が取得された公開鍵の有効性を検証し、検証結果通知手段が公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行い、メールクライアントの検証結果受信手段が前記検証結果通知手段による通知を受信する。なお、検証結果通知手段は、公開鍵検証手段による公開鍵の有効性の検証結果いかんにかかわらず、その検証結果をメールクライアントへ通知してもよいし、公開鍵が無効であった宛先が存在する場合にのみ、公開鍵が無効であった旨をメールクライアントへ通知してもよい。
【００５２】
これにより、通知を受けたメールクライアントは、公開鍵の有効性の検証結果を確認でき、電子メールを暗号化して送信できない宛先について認知することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００５３】
また、本発明に係る電子メールシステムでは、前記メールサーバーは、前記公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有することを特徴とする。この第２の抑止手段によって、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信が抑止されるので、他人に露呈したり有効期限切れとなって無効となってしまった公開鍵を使って暗号化された電子メールが宛先に送信されてしまい電子メールの内容が盗聴あるいは露呈してしまう危険を防止することができる。
【００５８】
また、本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントからの電子メールの暗号化機能に関する問合せに対し、自機が有する暗号化機能情報を応答する第１の応答手段を有し、前記メールクライアントが、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、前記暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信する送信手段と、を有することを特徴とする。
【００５９】
この電子メールシステムでは、メールクライアントの問合せ手段がメールサーバーに対して電子メールの暗号化機能に関する問い合わせを行うと、メールサーバーの第１の応答手段が上記問合せに対し、自機が有する暗号化機能情報を応答する。ここでメールサーバーが電子メールの暗号化機能を有しないと判明した場合、メールクライアントは、以下のように自ら電子メールの暗号化を行う。即ち、メールクライアントの公開鍵取得手段が、宛先情報に含まれた各宛先の公開鍵を取得し、公開鍵検証手段が前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証し、そして、暗号化手段は、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する。この暗号化された電子メールと宛先情報は、メールクライアントの送信手段によりメールサーバーに送信され、メールサーバーにより所定の宛先へ送信される。これにより、メールクライアントが、暗号化機能を備えたメールサーバーに接続できない環境では、メールクライアント側で電子メールを暗号化して送信するよう切り替えることが可能となる。
【００６４】
また、本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有し、前記メールクライアントが、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、を有することを特徴とする。
【００６５】
この電子メールシステムでは、メールサーバーが、公開鍵取得手段と、公開鍵検証手段と、暗号化手段と、暗号化された電子メールの送信手段とを備えているが、メールサーバーの検証結果通知手段が、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行うと、メールクライアントの検証結果受信手段が上記公開鍵の有効性の検証結果情報をメールサーバーから受信し、第２の宛先再設定手段が、受信された検証結果情報に基づいて宛先を再設定する。これにより、メールサーバーからの通知を受けたメールクライアントは、電子メールを暗号化して送信できない宛先について確認することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００７１】
【発明の実施の形態】
［第１実施形態］
以下、本発明の第１実施形態について、図面を参照しながら詳細に説明する。
【００７２】
図１には、第１実施形態のメールサーバー１０とメールクライアント３０の機能ブロック及びネットワーク構成を示している。
【００７３】
ネットワーク５０には、メールを作成し送信するメールクライアント３０と、メールクライアント３０がメールの送信を依頼するメールサーバー１０と、メールの宛先の公開鍵を保持する公開鍵サーバー５１とが接続されている。
【００７４】
［第１実施形態のメールサーバー１０の構成］
先ず、メールサーバー１０の機能ブロックについて説明する。図１に示すように、メールサーバー１０は、ネットワーク通信部１１、電子メール送信依頼受信部１２、暗号化指示受信部１３、公開鍵取得部１４、公開鍵エラー通知部１５、宛先除外部１６、公開鍵有効性検証部１７、機能問合せ応答部１８、電子メール送信部１９、及びメール暗号化部２０を含んで構成される。以下、各機能ブロックを順に説明する。
【００７５】
ネットワーク通信部１１は、ネットワーク５０と接続して、メールクライアント３０や公開鍵サーバー５１と通信を行う部分である。メールクライアント３０から送信される電子メールの送信依頼の受信、メールクライアント３０から送信される暗号化指示の受信や、メールクライアント３０から送信される暗号化機能の問合せ要求の受信と応答の送信、宛先の公開鍵の取得エラーや公開鍵の無効エラーの通知送信、宛先への電子メールの送信、公開鍵取得のための公開鍵サーバー５１との通信などを行う。
【００７６】
電子メール送信依頼受信部１２は、メールクライアント３０から、電子メールデータや宛先情報を含む電子メール送信依頼を受信する。メールクライアント３０が、ＳＭＴＰで送信を行う場合には、ＤＡＴＡコマンドやＲＣＰＴコマンドにより電子メールデータと宛先情報が受信される。また、メールサーバー１０がＨＴＴＰサーバーの機能を有しＷＥＢサーバーとなっている場合には、メールクライアント３０のＷＥＢブラウザから、ＨＴＴＰのＰＯＳＴメソッドにより、電子メールデータと宛先情報を含む送信依頼要求が受信される。
【００７７】
暗号化指示受信部１３は、電子メール送信依頼受信部１２が受信した電子メールデータをメールサーバー１０で暗号化する旨の指示をメールクライアント３０から受信する部分である。暗号化指示は、メールクライアント３０からＳＭＴＰの拡張コマンドあるいはＨＴＴＰのＰＯＳＴメソッドにより送信されるデータにより指示される。
【００７８】
公開鍵取得部１４は、暗号化指示受信部１３が電子メールの暗号化指示を受信した場合に、メールサーバー１０で電子メールを宛先ごとに暗号化するための公開鍵を取得する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得される。もちろん、本発明は、本実施形態に限定されるわけでなく、公開鍵の取得を、例えば、メールサーバー１０に予め公開鍵を格納してき、その公開鍵レポジトリ（図示せず）から取得するようにしてもよい。
【００７９】
公開鍵エラー通知部１５は、公開鍵取得部１４が公開鍵を取得できなかった場合、あるいは、公開鍵有効性検証部１７により、取得した公開鍵が無効であると判定された場合に、電子メールの暗号化ができない宛先についてメールクライアント３０に通知を行う部分である。通知は、電子メールによりＳＭＴＰでメールクライアント３０に通知するか、あるいは、メールクライアント３０のＷＥＢブラウザからのＨＴＴＰのＧＥＴメソッドあるいはＰＯＳＴメソッドの応答として通知する。
【００８０】
宛先除外部１６は、公開鍵取得部１４が公開鍵を取得できなかった宛先、あるいは、公開鍵有効性検証部１７により公開鍵が無効であると判定された宛先が、存在する場合に、電子メール送信依頼受信部１２がメールクライアント３０から送信依頼された宛先情報の宛先から、電子メールの暗号化できない宛先のみを除外した宛先情報を生成する部分である。
【００８１】
公開鍵有効性検証部１７は、公開鍵取得部１４が取得した公開鍵の有効性を検証する部分である。公開鍵の有効性は、公開鍵の有効期限が切れていないか、公開鍵の廃棄要求が認証局より発効されていないか、あるいは、公開鍵の証明書の認証局の署名が正しいかなどにより検証される。
【００８２】
機能問合せ応答部１８は、メールクライアント３０から送信された、メールサーバー１０の電子メールの暗号化機能に関する問合せを受信し、これに対する応答を送信する部分である。
【００８３】
電子メール送信部１９は、電子メール送信依頼受信部１２が、メールクライアント３０から受信した電子メールデータと宛先情報に従って、電子メールを宛先情報の各宛先に対して送信する部分である。宛先のアドレス情報に応じて、最適なメール転送サーバーに電子メールデータを送信する。また、暗号化指示受信部１３が、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、メール暗号化部２０で暗号化した電子メールを各宛先に対して送信する。
【００８４】
メール暗号化部２０は、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、公開鍵取得部１４が取得した宛先の公開鍵を使って、電子メールデータを暗号化する部分である。
【００８５】
［第１実施形態のメールクライアント３０の構成］
次に、メールクライアント３０の機能ブロックについて説明する。図１に示すように、メールクライアント３０は、操作表示部３１、電子メール生成部３２、電子メール送信依頼部３３、公開鍵取得検証部３４、メール暗号化部３５、宛先再設定部３６、通知受信部３７、暗号化指示部３８、機能問合せ部３９、及びネットワーク通信部４０を含んで構成される。以下、各機能ブロックを順に説明する。
【００８６】
操作表示部３１は、操作画面の表示や暗号化送信エラー時の表示、ユーザーが送信すべき電子メールの内容や宛先の入力、送信する電子メールの暗号化指示や、電子メールの送信指示などを行う部分である。
【００８７】
電子メール生成部３２は、操作表示部３１からユーザーが入力した電子メールの内容や宛先情報からメールサーバー１０に送信可能な形態の電子メールデータを生成する部分である。メールサーバー１０にＳＭＴＰで送信依頼を行なう場合には、ＩＥＴＦのＲＦＣ８２２で規定された電子メールフォーマットのデータを生成する。また、メールサーバー１０とにＨＴＴＰで送信依頼を行なう場合には、メールサーバー１０にＰＯＳＴメソッドでメールサーバー１０で決めれたフォーマットのデータを生成する。
【００８８】
電子メール送信依頼部３３は、電子メール生成部３２が生成した電子メールデータをネットワーク通信部４０を介してメールサーバーに送信依頼する部分である。メールサーバー１０への電子メールを送信依頼する方法としては、ＳＭＴＰを利用する方法と、ＨＴＴＰを利用する方法がある。
【００８９】
公開鍵取得検証部３４は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に必要となる宛先の公開鍵を取得しその有効性を検証する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得しその有効性を検証する。もちろん、本発明は本実施形態に限定されるわけでなく、公開鍵の取得を、ネットワーク上の公開鍵サーバー５１からでなく、メールクライアント３０に予め格納しておいた公開鍵レポジトリ（図示せず）から取得するようにしてもよい。
【００９０】
メール暗号化部３５は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に、公開鍵取得検証部３４が取得し有効性を検証した宛先の公開鍵を使って、電子メール生成部３２が生成した電子メールの暗号化を行う部分である。
【００９１】
宛先再設定部３６は、通知受信部３７が受信したメールサーバー１０からの電子メールの暗号化ができない宛先の通知情報を基に、操作表示部３１でユーザーが入力した宛先情報の宛先から電子メールの暗号化が不可能な宛先を除外した宛先に宛先情報を再設定する部分である。
【００９２】
通知受信部３７は、メールサーバー１０から通知されるメールサーバー１０で電子メールの暗号化ができない宛先の通知情報を受信する部分である。
【００９３】
暗号化指示部３８は、メールサーバー１０に対して、電子メール送信依頼部３３が送信依頼した電子メールを暗号化するようにメールサーバー１０へ指示する部分である。
【００９４】
機能問合せ部３９は、メールサーバー１０にメールサーバー１０が電子メールの暗号化機能を有するか問い合わせて、メールサーバー１０から暗号化機能の能力情報を受信する部分である。
【００９５】
ネットワーク通信部４０は、ネットワーク５０と接続して、メールサーバー１０や公開鍵サーバー５１と通信を行う部分である。メールサーバー１０への電子メールの送信依頼の送信や、メールサーバー１０への電子メールの暗号化指示の送信、メールサーバー１０への暗号化機能の問合せ要求の送信と応答の受信、宛先の公開鍵の取得エラーや無効通知の受信、公開鍵の取得のための公開鍵サーバー５１との通信などを行う。
【００９６】
［第１実施形態のメールサーバー１０による電子メールの送信処理］
次に、メールサーバー１０による電子メールの送信処理のフローを、図２に沿って説明する。
【００９７】
メールサーバー１０は、電子メール送信依頼受信部１２で、メールクライアント３０から電子メールの送信依頼を受信すると、まずステップＳ１０で、暗号化指示受信部１３により、電子メールの暗号化が指示されているかどうかをチェックする。電子メールの送信依頼は、メールクライアント３０との通信がＳＭＴＰであれば、ＤＡＴＡコマンドによる電子メールデータとＲＣＰＴコマンドによる宛先情報の送信により行われる。また、メールクライアント３０との通信がＨＴＴＰであれば、例えば、ＰＯＳＴメソッドにより送信される入力要素データ名"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=Expired Public Key"というフィールドがメールヘッダに挿入されることになる。
【０１５７】
ここで、署名検証結果が無効となった場合に、電子メールデータを削除するように、メールサーバー６０が設定されていた場合には、メールサーバー６０が電子メール受信蓄積部６２に蓄積された電子メールを自動的に削除するようにすることもできる。
【０１５８】
次のステップＳ５５では、電子メール送信部６８が、メールクライアント７０からの、電子メール取出し要求を受信するまで待機を行なう。電子メール取出し要求が受信されると、ステップＳ５６に進み、電子メール送信部６８が、署名検証結果をメールヘッダに挿入した電子メールを、メールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。また、例えば、メールサーバー６０が、ＨＴＴＰサーバーであるＷＥＢサーバー機能を有する場合には、メールクライアント７０のＷＥＢブラウザからの指示により、電子メールの取出し要求としてＨＴＴＰが利用される。この場合、電子メールは、ＨＴＭＬに変換されて送信される。
【０１５９】
一方、ステップＳ５３でメールサーバー６０が署名検証結果挿入モードでないと判定された場合、ステップＳ５７へ進み、メールクライアント７０からの電子メール取出し要求があるまで待機する。そして、電子メール取出し要求が受信されると、ステップＳ５８へ進み、電子メール送信部６８が、電子メール受信蓄積部６２により受信蓄積された電子メール（署名検証結果が挿入されていない電子メール）をメールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。
【０１６０】
次のステップＳ５９では、署名検証結果応答部６６が、メールクライアント７０から、署名検証結果の問合せ要求があるまで待機を行ない、メールクライアント７０から、署名検証結果の問合せ要求が受信されると、次のステップＳ６０で署名検証結果をメールクライアント７０に応答する。
【０１６１】
以上説明したように、第２実施形態のメールサーバー６０は、受信蓄積した電子メールに電子署名がなされている場合に、この電子署名を検証し、その検証結果を、自動的に電子メールに挿入するか、あるいは、メールクライアント７０からの問合せに対して応答するので、電子署名の検証機能を有していない携帯端末のようなメールクライアントでも、電子署名の検証結果を確認することが可能となる。また、署名検証のために必要となる、署名者の公開鍵の取得や有効性検証といった煩雑な処理を、メールクライアントではなくメールサーバで行なうようにすることができる。
【０１６２】
［第２実施形態のメールクライアント７０による電子メールの受信処理］
次に、メールクライアント７０による電子メールの取得処理のフローを、図６に沿って説明する。
【０１６３】
メールクライアント７０において、ユーザーが操作表示部７１から電子メールの取得を要求すると、先ず、ステップＳ７０で、電子メール取得部７２が、メールサーバー６０に対して、電子メールの取得要求を発行し、その応答として電子メールの受信を行ない、次に、ステップＳ７１で、受信した電子メールのメールヘッダに署名検証結果が挿入されているかどうかをチェックする。署名検証結果の挿入は、電子メールのメールヘッダに"X-Ｓingnature-Verify:"というフィールド名のフィールドが存在するかどうかを判定して行なう。
【０１６４】
署名検証結果が電子メールに挿入されていれば、ステップＳ７４に進み、取得した電子メールの内容とその署名検証結果を操作表示部７１に表示する。一方、署名検証結果が電子メールに挿入されていない場合には、ステップＳ７２に進み、メールクライアント７０が署名検証結果問合せモードに設定されているか判定する。
【０１６５】
なお、署名検証結果問合せモードの設定は、メールクライアント７０のユーザーが予め設定する。署名検証結果問合せモードをオンに設定した場合には、機能問合せ部７４が、メールサーバー６０に署名検証機能の能力問合せを行ない、メールサーバー７０が署名検証機能を有する場合のみオンに設定できるようになっている。メールサーバー７０が署名検証機能を有しない場合には、署名検証結果問合せモードの設定オフに自動的にリセットされる。
【０１６６】
メールクライアント７０が署名検証結果問合せモードに設定されている場合は、ステップＳ７３に進み、署名検証結果問合せ部７３が、メールサーバー６０に、ステップＳ７０で取得した電子メールの署名検証結果を問い合わせる。そして、次のステップＳ７４で、取得した電子メールとその署名検証結果を操作表示部７１に表示して処理を終了する。
【０１６７】
一方、ステップＳ７２でメールクライアント７０が、署名検証結果問合せモードに設定されていない場合には、ステップＳ７５へ進み、取得した電子メールを操作表示部７１に表示して処理を終了する。
【０１６８】
以上説明したように、第２実施形態のメールクライアント７０は、メールサーバー６０から取得した電子メールに、署名検証結果が挿入されていないか判定し、もし挿入されていれば、電子メールの内容とともにその署名検証結果も表示する。
【０１６９】
また、署名検証結果が電子メールに挿入されていない場合には、メールサーバー６０が署名検証機能を持っていれば、メールサーバー６０に対して、取得した電子メールの署名検証結果を問い合わせて、電子メールの内容とともにその署名検証結果も表示するので、メールクライアントが電子メールの署名検証機能を有していない場合でも、電子署名の検証結果を確認することが可能となる。例えば、メールクライアントがＷＥＢブラウザであり、メール取得プロトコルと異なるプロトコルしか有していない場合にも、受信メールの電子署名の検証結果を確認することができる。
【０１７０】
【発明の効果】
以上説明したように、本発明によれば、メールクライアントは、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて、電子メールの暗号化及びその送信について臨機応変な対応を行うことができる。即ち、メールクライアントは、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知により、電子メールを暗号化して送信できない宛先について認知した上で、電子メールの暗号化送信を中止するか、あるいは、暗号化可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理を選択して実行することが可能となる。
【０１７１】
また、電子メールの暗号化に必要となる宛先の公開鍵の管理や有効性検証など煩雑な処理をメールクライアントではなく、メールサーバーで行なうので、携帯端末のような資源の限られたメールクライアントでも安全に電子メールを暗号化して送信することが可能となる。
【０１７２】
また、本発明のメールサーバーは、受信した電子メールに電子署名がなされている場合に、電子署名の検証を行ない、その検証結果をメールクライアントに通知するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果を確認することが可能となる。また、電子メールの署名検証に必要となる署名者の公開鍵の管理や有効性検証など煩雑な処理をメールクライアントではなく、メールサーバーで行なうので、携帯端末のような資源の限られたメールクライアントでも安全に電子メールの署名検証結果を確認することが可能となる。
【０１７３】
また、本発明のメールクライアントは、メールサーバーが電子メールの署名検証機能を持つかどうか問い合わせ、メールサーバーで電子メールの署名検証が可能な場合には、メールサーバーに電子メールの署名検証結果を送信するよう指示したり、あるいは、取得した電子メールに挿入されている署名検証結果を識別判断するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果の確認が可能となる。
【図面の簡単な説明】
【図１】 本発明の第１実施形態におけるメールサーバー１０とメールクライアント３０の機能ブロック図及びネットワーク構成を示す図である。
【図２】 本発明の第１実施形態におけるメールサーバー１０による電子メールの暗号化送信のフローチャートである。
【図３】 本発明の第１実施形態におけるメールクライアント３０による電子メールの送信処理のフローチャートである。
【図４】 本発明の第２実施形態におけるメールサーバー６０とメールクライアント７０の機能ブロック図及びネットワーク構成を示す図である。
【図５】 本発明の第２実施形態におけるメールサーバー６０による電子メールの受信処理のフローチャートである。
【図６】 本発明の第２実施形態におけるメールクライアント７０による電子メールの取得処理のフローチャートである。
【符号の説明】
１０、６０ メールサーバー
３０、７０ メールクライアント
５０、８０ ネットワーク
５１、８１ 公開鍵サーバー
１１、４０、６１、７５ ネットワーク通信部
１２ 電子メール送信依頼受信部
１３ 暗号化指示受信部
１４、６４ 公開鍵取得部
１５ 公開鍵エラー通知部
１６ 宛先除外部
１７ 公開鍵有効性検証部
１８、６７ 機能問合せ応答部
１９、６８ 電子メール送信部
２０、３５ メール暗号化部
３１、７１ 操作表示部
３２ 電子メール生成部
３３ 電子メール送信依頼部
３４ 公開鍵取得検証部
３６ 宛先再設定部
３７ 通知受信部
３８ 暗号化指示部
３９、７４ 機能問合せ部
６２ 電子メール受信蓄積部
６３ 署名検知部
６５ 署名検証部
６６ 署名検証結果応答部
６９ 署名検証結果挿入部
７２ 電子メール取得部
７３ 署名検証結果問合せ部
【発明の属する技術分野】
本発明は、メールサーバー、メールクライアント及び電子メールシステムに係り、より詳しくは、メールクライアントから電子メール及び宛先情報を受信し当該電子メールを宛先情報の宛先に送信するメールサーバー、送信すべき電子メール及び宛先情報をメールサーバーに送信するメールクライアント、及びこれら両者を含んで構成された電子メールシステムに関する。
【０００２】
【従来の技術】
近年、公開鍵暗号技術、共通鍵暗号技術、および、メッセージダイジェスト技術を利用した暗号電子メールが実用されており、この暗号電子メールを利用することで、電子メールの秘匿や改竄防止、送信者認証の機能を実現することが可能となる。
【０００３】
このような暗号電子メールとしては、電子メールのＭＩＭＥ(Multipurpose Internet Mail Extension)機能を利用して暗号電子メールを取り扱えるようにしたＳ／ＭＩＭＥ(Secure MIME)やＰＧＰ／ＭＩＭＥ(Pretty Good Privacy 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（米国Microsoft Corporationの登録商標）がある。
【００１３】
ＷＥＢメールでは、ＷＥＢブラウザで入力した電子メールの内容と宛先指定がＨＴＴＰ(Hyper Text Transfer Protocol)により、ＷＥＢサーバーに送信される。ＷＥＢサーバーでは、ＨＴＴＰで受信した電子メールの内容と宛先情報から電子メールを生成し、ＳＭＴＰ(Simple Mail Transfer Protocol)で宛先に電子メール送信を行なう。
【００１４】
また、メールサーバーに受信した電子メールは、ＷＥＢサーバー上でＨＴＭＬ（Hyper Text Markup Language）に変換されＷＥＢブラウザの要求によりＨＴＴＰで送信される。
【００１５】
従来、このようなＷＥＢメールでは、暗号電子メールの機能をＷＥＢブラウザ自体が備えていないため、暗号電子メールを利用できず、秘匿性の高い内容のメールを暗号送信したり、受信メールの改竄検知を行なうことができなかった。
【００１６】
ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化に、ＳＳＬ(Security Socket Layer)などの通信路暗号技術を利用することが一般的に行われているが、この技術は、ＷＥＢブラウザとＷＥＢサーバー間の通信の暗号化であり、送受信される電子メール自体の暗号化ができなかったため、メール転送路上の秘匿の問題を解決できなかった。
【００１７】
【発明が解決しようとする課題】
本発明は、上記課題を解決するために成されたものであり、メールクライアントが電子メールの暗号化機能を持たない場合でも、電子メールを暗号化して所望の宛先に送信することを可能としつつ、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて電子メールの暗号化及びその送信について臨機応変な対応を行うことができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００１８】
また、携帯端末のような資源の限られたメールクライアントからでも安全に電子メールを暗号化して送信することができるメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００１９】
さらに、メールクライアントが電子メールの署名検証機能を持たない場合でも、受信された電子メールの電子署名を検証させ該署名検証結果を確認可能としたメールクライアント、メールサーバー及び電子メールシステムを提供することを目的とする。
【００２０】
【課題を解決するための手段】
【００２４】
本発明に係るメールサーバーは、メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有することを特徴とする。
【００２５】
本発明に係るメールサーバーでは、受信手段がメールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信すると、公開鍵取得手段が、受信された宛先情報に含まれた各宛先の公開鍵を取得する。そして、暗号化手段が、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化し、送信手段が暗号化された電子メールを各宛先に送信する。このメールサーバーの特徴として、公開鍵検証手段が取得された公開鍵の有効性を検証し、検証結果通知手段が公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行う。即ち、検証結果通知手段は、公開鍵検証手段による公開鍵の有効性の検証結果いかんにかかわらず、その検証結果をメールクライアントへ通知してもよいし、公開鍵が無効であった宛先が存在する場合にのみ、公開鍵が無効であった旨をメールクライアントへ通知してもよい。
【００２６】
これにより、通知を受けたメールクライアントは、公開鍵の有効性の検証結果を確認でき、電子メールを暗号化して送信できない宛先について認知することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００２７】
また、本発明に係るメールサーバーは、上記のメールサーバーにおいて、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有することを特徴とする。この第２の抑止手段によって、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信が抑止されるので、他人に露呈したり有効期限切れとなって無効となってしまった公開鍵を使って暗号化された電子メールが宛先に送信されてしまい電子メールの内容が盗聴あるいは露呈してしまう危険を防止することができる。
【００３３】
本発明に係るメールクライアントは、送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、を有し、前記送信手段は、前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、自機の暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信することを特徴とする。
【００３４】
このメールクライアントは、上記公開鍵取得手段と公開鍵検証手段と暗号化手段とを備えており、問合せ手段による問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明すると、メールクライアントが備えた公開鍵取得手段により宛先の公開鍵を取得し、公開鍵検証手段により前記公開鍵取得手段が取得した公開鍵の有効性を検証する。そして、暗号化手段が前記公開鍵有効性検証手段により有効であると判定された宛先の公開鍵を使って電子メールを暗号化してメールサーバーに送信する。このため、暗号化機能を有するメールサーバーに接続できない環境では、メールクライアント側で電子メールを暗号化して送信するよう切り替えることが可能となる。
【００３７】
また、本発明に係るメールクライアントは、送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、を有することを特徴とする。このメールクライアントでは、検証結果受信手段が、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信すると、第２の宛先再設定手段が、受信された検証結果情報に基づいて宛先を再設定するので、電子メールの暗号化送信が可能な宛先へのみ、電子メールを暗号化して送信するようメールサーバーに指示できるようになる。
【００５０】
本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有し、前記メールクライアントが、前記検証結果通知手段による通知を受信する検証結果受信手段を有することを特徴とする。
【００５１】
この電子メールシステムでは、メールサーバーの受信手段がメールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信すると、公開鍵取得手段が、受信された宛先情報に含まれた各宛先の公開鍵を取得する。そして、暗号化手段が、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化し、送信手段が暗号化された電子メールを各宛先に送信する。この請求項１７記載の電子メールシステムの特徴として、メールサーバーにて、公開鍵検証手段が取得された公開鍵の有効性を検証し、検証結果通知手段が公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行い、メールクライアントの検証結果受信手段が前記検証結果通知手段による通知を受信する。なお、検証結果通知手段は、公開鍵検証手段による公開鍵の有効性の検証結果いかんにかかわらず、その検証結果をメールクライアントへ通知してもよいし、公開鍵が無効であった宛先が存在する場合にのみ、公開鍵が無効であった旨をメールクライアントへ通知してもよい。
【００５２】
これにより、通知を受けたメールクライアントは、公開鍵の有効性の検証結果を確認でき、電子メールを暗号化して送信できない宛先について認知することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００５３】
また、本発明に係る電子メールシステムでは、前記メールサーバーは、前記公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有することを特徴とする。この第２の抑止手段によって、公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信が抑止されるので、他人に露呈したり有効期限切れとなって無効となってしまった公開鍵を使って暗号化された電子メールが宛先に送信されてしまい電子メールの内容が盗聴あるいは露呈してしまう危険を防止することができる。
【００５８】
また、本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントからの電子メールの暗号化機能に関する問合せに対し、自機が有する暗号化機能情報を応答する第１の応答手段を有し、前記メールクライアントが、前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、前記暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信する送信手段と、を有することを特徴とする。
【００５９】
この電子メールシステムでは、メールクライアントの問合せ手段がメールサーバーに対して電子メールの暗号化機能に関する問い合わせを行うと、メールサーバーの第１の応答手段が上記問合せに対し、自機が有する暗号化機能情報を応答する。ここでメールサーバーが電子メールの暗号化機能を有しないと判明した場合、メールクライアントは、以下のように自ら電子メールの暗号化を行う。即ち、メールクライアントの公開鍵取得手段が、宛先情報に含まれた各宛先の公開鍵を取得し、公開鍵検証手段が前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証し、そして、暗号化手段は、前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する。この暗号化された電子メールと宛先情報は、メールクライアントの送信手段によりメールサーバーに送信され、メールサーバーにより所定の宛先へ送信される。これにより、メールクライアントが、暗号化機能を備えたメールサーバーに接続できない環境では、メールクライアント側で電子メールを暗号化して送信するよう切り替えることが可能となる。
【００６４】
また、本発明に係る電子メールシステムは、ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、前記メールサーバーが、前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、暗号化された電子メールを各宛先に送信する送信手段と、前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、を有し、前記メールクライアントが、メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、を有することを特徴とする。
【００６５】
この電子メールシステムでは、メールサーバーが、公開鍵取得手段と、公開鍵検証手段と、暗号化手段と、暗号化された電子メールの送信手段とを備えているが、メールサーバーの検証結果通知手段が、前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知をメールクライアントに対して行うと、メールクライアントの検証結果受信手段が上記公開鍵の有効性の検証結果情報をメールサーバーから受信し、第２の宛先再設定手段が、受信された検証結果情報に基づいて宛先を再設定する。これにより、メールサーバーからの通知を受けたメールクライアントは、電子メールを暗号化して送信できない宛先について確認することが可能となる。また、メールクライアントは、この通知に応じて、電子メールの暗号化送信を中止するか、あるいは、暗号化送信可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理が可能となる。
【００７１】
【発明の実施の形態】
［第１実施形態］
以下、本発明の第１実施形態について、図面を参照しながら詳細に説明する。
【００７２】
図１には、第１実施形態のメールサーバー１０とメールクライアント３０の機能ブロック及びネットワーク構成を示している。
【００７３】
ネットワーク５０には、メールを作成し送信するメールクライアント３０と、メールクライアント３０がメールの送信を依頼するメールサーバー１０と、メールの宛先の公開鍵を保持する公開鍵サーバー５１とが接続されている。
【００７４】
［第１実施形態のメールサーバー１０の構成］
先ず、メールサーバー１０の機能ブロックについて説明する。図１に示すように、メールサーバー１０は、ネットワーク通信部１１、電子メール送信依頼受信部１２、暗号化指示受信部１３、公開鍵取得部１４、公開鍵エラー通知部１５、宛先除外部１６、公開鍵有効性検証部１７、機能問合せ応答部１８、電子メール送信部１９、及びメール暗号化部２０を含んで構成される。以下、各機能ブロックを順に説明する。
【００７５】
ネットワーク通信部１１は、ネットワーク５０と接続して、メールクライアント３０や公開鍵サーバー５１と通信を行う部分である。メールクライアント３０から送信される電子メールの送信依頼の受信、メールクライアント３０から送信される暗号化指示の受信や、メールクライアント３０から送信される暗号化機能の問合せ要求の受信と応答の送信、宛先の公開鍵の取得エラーや公開鍵の無効エラーの通知送信、宛先への電子メールの送信、公開鍵取得のための公開鍵サーバー５１との通信などを行う。
【００７６】
電子メール送信依頼受信部１２は、メールクライアント３０から、電子メールデータや宛先情報を含む電子メール送信依頼を受信する。メールクライアント３０が、ＳＭＴＰで送信を行う場合には、ＤＡＴＡコマンドやＲＣＰＴコマンドにより電子メールデータと宛先情報が受信される。また、メールサーバー１０がＨＴＴＰサーバーの機能を有しＷＥＢサーバーとなっている場合には、メールクライアント３０のＷＥＢブラウザから、ＨＴＴＰのＰＯＳＴメソッドにより、電子メールデータと宛先情報を含む送信依頼要求が受信される。
【００７７】
暗号化指示受信部１３は、電子メール送信依頼受信部１２が受信した電子メールデータをメールサーバー１０で暗号化する旨の指示をメールクライアント３０から受信する部分である。暗号化指示は、メールクライアント３０からＳＭＴＰの拡張コマンドあるいはＨＴＴＰのＰＯＳＴメソッドにより送信されるデータにより指示される。
【００７８】
公開鍵取得部１４は、暗号化指示受信部１３が電子メールの暗号化指示を受信した場合に、メールサーバー１０で電子メールを宛先ごとに暗号化するための公開鍵を取得する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得される。もちろん、本発明は、本実施形態に限定されるわけでなく、公開鍵の取得を、例えば、メールサーバー１０に予め公開鍵を格納してき、その公開鍵レポジトリ（図示せず）から取得するようにしてもよい。
【００７９】
公開鍵エラー通知部１５は、公開鍵取得部１４が公開鍵を取得できなかった場合、あるいは、公開鍵有効性検証部１７により、取得した公開鍵が無効であると判定された場合に、電子メールの暗号化ができない宛先についてメールクライアント３０に通知を行う部分である。通知は、電子メールによりＳＭＴＰでメールクライアント３０に通知するか、あるいは、メールクライアント３０のＷＥＢブラウザからのＨＴＴＰのＧＥＴメソッドあるいはＰＯＳＴメソッドの応答として通知する。
【００８０】
宛先除外部１６は、公開鍵取得部１４が公開鍵を取得できなかった宛先、あるいは、公開鍵有効性検証部１７により公開鍵が無効であると判定された宛先が、存在する場合に、電子メール送信依頼受信部１２がメールクライアント３０から送信依頼された宛先情報の宛先から、電子メールの暗号化できない宛先のみを除外した宛先情報を生成する部分である。
【００８１】
公開鍵有効性検証部１７は、公開鍵取得部１４が取得した公開鍵の有効性を検証する部分である。公開鍵の有効性は、公開鍵の有効期限が切れていないか、公開鍵の廃棄要求が認証局より発効されていないか、あるいは、公開鍵の証明書の認証局の署名が正しいかなどにより検証される。
【００８２】
機能問合せ応答部１８は、メールクライアント３０から送信された、メールサーバー１０の電子メールの暗号化機能に関する問合せを受信し、これに対する応答を送信する部分である。
【００８３】
電子メール送信部１９は、電子メール送信依頼受信部１２が、メールクライアント３０から受信した電子メールデータと宛先情報に従って、電子メールを宛先情報の各宛先に対して送信する部分である。宛先のアドレス情報に応じて、最適なメール転送サーバーに電子メールデータを送信する。また、暗号化指示受信部１３が、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、メール暗号化部２０で暗号化した電子メールを各宛先に対して送信する。
【００８４】
メール暗号化部２０は、メールクライアント３０から電子メールデータの暗号化指示を受信した場合には、公開鍵取得部１４が取得した宛先の公開鍵を使って、電子メールデータを暗号化する部分である。
【００８５】
［第１実施形態のメールクライアント３０の構成］
次に、メールクライアント３０の機能ブロックについて説明する。図１に示すように、メールクライアント３０は、操作表示部３１、電子メール生成部３２、電子メール送信依頼部３３、公開鍵取得検証部３４、メール暗号化部３５、宛先再設定部３６、通知受信部３７、暗号化指示部３８、機能問合せ部３９、及びネットワーク通信部４０を含んで構成される。以下、各機能ブロックを順に説明する。
【００８６】
操作表示部３１は、操作画面の表示や暗号化送信エラー時の表示、ユーザーが送信すべき電子メールの内容や宛先の入力、送信する電子メールの暗号化指示や、電子メールの送信指示などを行う部分である。
【００８７】
電子メール生成部３２は、操作表示部３１からユーザーが入力した電子メールの内容や宛先情報からメールサーバー１０に送信可能な形態の電子メールデータを生成する部分である。メールサーバー１０にＳＭＴＰで送信依頼を行なう場合には、ＩＥＴＦのＲＦＣ８２２で規定された電子メールフォーマットのデータを生成する。また、メールサーバー１０とにＨＴＴＰで送信依頼を行なう場合には、メールサーバー１０にＰＯＳＴメソッドでメールサーバー１０で決めれたフォーマットのデータを生成する。
【００８８】
電子メール送信依頼部３３は、電子メール生成部３２が生成した電子メールデータをネットワーク通信部４０を介してメールサーバーに送信依頼する部分である。メールサーバー１０への電子メールを送信依頼する方法としては、ＳＭＴＰを利用する方法と、ＨＴＴＰを利用する方法がある。
【００８９】
公開鍵取得検証部３４は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に必要となる宛先の公開鍵を取得しその有効性を検証する部分である。公開鍵は、ネットワーク５０に接続する公開鍵サーバー５１から取得しその有効性を検証する。もちろん、本発明は本実施形態に限定されるわけでなく、公開鍵の取得を、ネットワーク上の公開鍵サーバー５１からでなく、メールクライアント３０に予め格納しておいた公開鍵レポジトリ（図示せず）から取得するようにしてもよい。
【００９０】
メール暗号化部３５は、メールサーバー１０が電子メールの暗号機能を持っておらずメールクライアント３０で電子メールを暗号化する場合に、公開鍵取得検証部３４が取得し有効性を検証した宛先の公開鍵を使って、電子メール生成部３２が生成した電子メールの暗号化を行う部分である。
【００９１】
宛先再設定部３６は、通知受信部３７が受信したメールサーバー１０からの電子メールの暗号化ができない宛先の通知情報を基に、操作表示部３１でユーザーが入力した宛先情報の宛先から電子メールの暗号化が不可能な宛先を除外した宛先に宛先情報を再設定する部分である。
【００９２】
通知受信部３７は、メールサーバー１０から通知されるメールサーバー１０で電子メールの暗号化ができない宛先の通知情報を受信する部分である。
【００９３】
暗号化指示部３８は、メールサーバー１０に対して、電子メール送信依頼部３３が送信依頼した電子メールを暗号化するようにメールサーバー１０へ指示する部分である。
【００９４】
機能問合せ部３９は、メールサーバー１０にメールサーバー１０が電子メールの暗号化機能を有するか問い合わせて、メールサーバー１０から暗号化機能の能力情報を受信する部分である。
【００９５】
ネットワーク通信部４０は、ネットワーク５０と接続して、メールサーバー１０や公開鍵サーバー５１と通信を行う部分である。メールサーバー１０への電子メールの送信依頼の送信や、メールサーバー１０への電子メールの暗号化指示の送信、メールサーバー１０への暗号化機能の問合せ要求の送信と応答の受信、宛先の公開鍵の取得エラーや無効通知の受信、公開鍵の取得のための公開鍵サーバー５１との通信などを行う。
【００９６】
［第１実施形態のメールサーバー１０による電子メールの送信処理］
次に、メールサーバー１０による電子メールの送信処理のフローを、図２に沿って説明する。
【００９７】
メールサーバー１０は、電子メール送信依頼受信部１２で、メールクライアント３０から電子メールの送信依頼を受信すると、まずステップＳ１０で、暗号化指示受信部１３により、電子メールの暗号化が指示されているかどうかをチェックする。電子メールの送信依頼は、メールクライアント３０との通信がＳＭＴＰであれば、ＤＡＴＡコマンドによる電子メールデータとＲＣＰＴコマンドによる宛先情報の送信により行われる。また、メールクライアント３０との通信がＨＴＴＰであれば、例えば、ＰＯＳＴメソッドにより送信される入力要素データ名"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=Expired Public Key"というフィールドがメールヘッダに挿入されることになる。
【０１５７】
ここで、署名検証結果が無効となった場合に、電子メールデータを削除するように、メールサーバー６０が設定されていた場合には、メールサーバー６０が電子メール受信蓄積部６２に蓄積された電子メールを自動的に削除するようにすることもできる。
【０１５８】
次のステップＳ５５では、電子メール送信部６８が、メールクライアント７０からの、電子メール取出し要求を受信するまで待機を行なう。電子メール取出し要求が受信されると、ステップＳ５６に進み、電子メール送信部６８が、署名検証結果をメールヘッダに挿入した電子メールを、メールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。また、例えば、メールサーバー６０が、ＨＴＴＰサーバーであるＷＥＢサーバー機能を有する場合には、メールクライアント７０のＷＥＢブラウザからの指示により、電子メールの取出し要求としてＨＴＴＰが利用される。この場合、電子メールは、ＨＴＭＬに変換されて送信される。
【０１５９】
一方、ステップＳ５３でメールサーバー６０が署名検証結果挿入モードでないと判定された場合、ステップＳ５７へ進み、メールクライアント７０からの電子メール取出し要求があるまで待機する。そして、電子メール取出し要求が受信されると、ステップＳ５８へ進み、電子メール送信部６８が、電子メール受信蓄積部６２により受信蓄積された電子メール（署名検証結果が挿入されていない電子メール）をメールクライアント７０に送信する。ここで、メールクライアント７０の電子メール取出しプロトコルとしては、例えば、ＰＯＰ３やＩＭＡＰ４などが利用される。
【０１６０】
次のステップＳ５９では、署名検証結果応答部６６が、メールクライアント７０から、署名検証結果の問合せ要求があるまで待機を行ない、メールクライアント７０から、署名検証結果の問合せ要求が受信されると、次のステップＳ６０で署名検証結果をメールクライアント７０に応答する。
【０１６１】
以上説明したように、第２実施形態のメールサーバー６０は、受信蓄積した電子メールに電子署名がなされている場合に、この電子署名を検証し、その検証結果を、自動的に電子メールに挿入するか、あるいは、メールクライアント７０からの問合せに対して応答するので、電子署名の検証機能を有していない携帯端末のようなメールクライアントでも、電子署名の検証結果を確認することが可能となる。また、署名検証のために必要となる、署名者の公開鍵の取得や有効性検証といった煩雑な処理を、メールクライアントではなくメールサーバで行なうようにすることができる。
【０１６２】
［第２実施形態のメールクライアント７０による電子メールの受信処理］
次に、メールクライアント７０による電子メールの取得処理のフローを、図６に沿って説明する。
【０１６３】
メールクライアント７０において、ユーザーが操作表示部７１から電子メールの取得を要求すると、先ず、ステップＳ７０で、電子メール取得部７２が、メールサーバー６０に対して、電子メールの取得要求を発行し、その応答として電子メールの受信を行ない、次に、ステップＳ７１で、受信した電子メールのメールヘッダに署名検証結果が挿入されているかどうかをチェックする。署名検証結果の挿入は、電子メールのメールヘッダに"X-Ｓingnature-Verify:"というフィールド名のフィールドが存在するかどうかを判定して行なう。
【０１６４】
署名検証結果が電子メールに挿入されていれば、ステップＳ７４に進み、取得した電子メールの内容とその署名検証結果を操作表示部７１に表示する。一方、署名検証結果が電子メールに挿入されていない場合には、ステップＳ７２に進み、メールクライアント７０が署名検証結果問合せモードに設定されているか判定する。
【０１６５】
なお、署名検証結果問合せモードの設定は、メールクライアント７０のユーザーが予め設定する。署名検証結果問合せモードをオンに設定した場合には、機能問合せ部７４が、メールサーバー６０に署名検証機能の能力問合せを行ない、メールサーバー７０が署名検証機能を有する場合のみオンに設定できるようになっている。メールサーバー７０が署名検証機能を有しない場合には、署名検証結果問合せモードの設定オフに自動的にリセットされる。
【０１６６】
メールクライアント７０が署名検証結果問合せモードに設定されている場合は、ステップＳ７３に進み、署名検証結果問合せ部７３が、メールサーバー６０に、ステップＳ７０で取得した電子メールの署名検証結果を問い合わせる。そして、次のステップＳ７４で、取得した電子メールとその署名検証結果を操作表示部７１に表示して処理を終了する。
【０１６７】
一方、ステップＳ７２でメールクライアント７０が、署名検証結果問合せモードに設定されていない場合には、ステップＳ７５へ進み、取得した電子メールを操作表示部７１に表示して処理を終了する。
【０１６８】
以上説明したように、第２実施形態のメールクライアント７０は、メールサーバー６０から取得した電子メールに、署名検証結果が挿入されていないか判定し、もし挿入されていれば、電子メールの内容とともにその署名検証結果も表示する。
【０１６９】
また、署名検証結果が電子メールに挿入されていない場合には、メールサーバー６０が署名検証機能を持っていれば、メールサーバー６０に対して、取得した電子メールの署名検証結果を問い合わせて、電子メールの内容とともにその署名検証結果も表示するので、メールクライアントが電子メールの署名検証機能を有していない場合でも、電子署名の検証結果を確認することが可能となる。例えば、メールクライアントがＷＥＢブラウザであり、メール取得プロトコルと異なるプロトコルしか有していない場合にも、受信メールの電子署名の検証結果を確認することができる。
【０１７０】
【発明の効果】
以上説明したように、本発明によれば、メールクライアントは、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知に基づいて、電子メールの暗号化及びその送信について臨機応変な対応を行うことができる。即ち、メールクライアントは、メールサーバーからの公開鍵の取得結果又は公開鍵の有効性の検証結果の通知により、電子メールを暗号化して送信できない宛先について認知した上で、電子メールの暗号化送信を中止するか、あるいは、暗号化可能な宛先のみに宛先を再設定して電子メールの暗号化送信を行なうなどの処理を選択して実行することが可能となる。
【０１７１】
また、電子メールの暗号化に必要となる宛先の公開鍵の管理や有効性検証など煩雑な処理をメールクライアントではなく、メールサーバーで行なうので、携帯端末のような資源の限られたメールクライアントでも安全に電子メールを暗号化して送信することが可能となる。
【０１７２】
また、本発明のメールサーバーは、受信した電子メールに電子署名がなされている場合に、電子署名の検証を行ない、その検証結果をメールクライアントに通知するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果を確認することが可能となる。また、電子メールの署名検証に必要となる署名者の公開鍵の管理や有効性検証など煩雑な処理をメールクライアントではなく、メールサーバーで行なうので、携帯端末のような資源の限られたメールクライアントでも安全に電子メールの署名検証結果を確認することが可能となる。
【０１７３】
また、本発明のメールクライアントは、メールサーバーが電子メールの署名検証機能を持つかどうか問い合わせ、メールサーバーで電子メールの署名検証が可能な場合には、メールサーバーに電子メールの署名検証結果を送信するよう指示したり、あるいは、取得した電子メールに挿入されている署名検証結果を識別判断するので、メールクライアントが電子メールの署名検証機能を持たない場合でも、電子メールの署名検証結果の確認が可能となる。
【図面の簡単な説明】
【図１】 本発明の第１実施形態におけるメールサーバー１０とメールクライアント３０の機能ブロック図及びネットワーク構成を示す図である。
【図２】 本発明の第１実施形態におけるメールサーバー１０による電子メールの暗号化送信のフローチャートである。
【図３】 本発明の第１実施形態におけるメールクライアント３０による電子メールの送信処理のフローチャートである。
【図４】 本発明の第２実施形態におけるメールサーバー６０とメールクライアント７０の機能ブロック図及びネットワーク構成を示す図である。
【図５】 本発明の第２実施形態におけるメールサーバー６０による電子メールの受信処理のフローチャートである。
【図６】 本発明の第２実施形態におけるメールクライアント７０による電子メールの取得処理のフローチャートである。
【符号の説明】
１０、６０ メールサーバー
３０、７０ メールクライアント
５０、８０ ネットワーク
５１、８１ 公開鍵サーバー
１１、４０、６１、７５ ネットワーク通信部
１２ 電子メール送信依頼受信部
１３ 暗号化指示受信部
１４、６４ 公開鍵取得部
１５ 公開鍵エラー通知部
１６ 宛先除外部
１７ 公開鍵有効性検証部
１８、６７ 機能問合せ応答部
１９、６８ 電子メール送信部
２０、３５ メール暗号化部
３１、７１ 操作表示部
３２ 電子メール生成部
３３ 電子メール送信依頼部
３４ 公開鍵取得検証部
３６ 宛先再設定部
３７ 通知受信部
３８ 暗号化指示部
３９、７４ 機能問合せ部
６２ 電子メール受信蓄積部
６３ 署名検知部
６５ 署名検証部
６６ 署名検証結果応答部
６９ 署名検証結果挿入部
７２ 電子メール取得部
７３ 署名検証結果問合せ部
Claims (8)
- メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、
前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、
前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、
暗号化された電子メールを各宛先に送信する送信手段と、
前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、
前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、
を有するメールサーバー。 - 前記公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有する請求項１記載のメールサーバー。
- 送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、
前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、
前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、
前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、
前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、
前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、
を有し、
前記送信手段は、前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、自機の暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信することを特徴とするメールクライアント。 - 送信すべき電子メール及び宛先情報をメールサーバーに送信する送信手段と、
前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、
前記問合せ手段によりメールサーバーが電子メールの暗号化機能を有すると判明した場合に、当該メールサーバーに対して電子メールを暗号化し暗号化後の電子メールを宛先に送信するよう指示する指示手段と、
メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、
受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、
を有するメールクライアント。 - ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、
前記メールサーバーが、
前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、
前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、
前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、
暗号化された電子メールを各宛先に送信する送信手段と、
前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、
前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、
を有し、
前記メールクライアントが、
前記検証結果通知手段による通知を受信する検証結果受信手段を有することを特徴とする電子メールシステム。 - 前記メールサーバーは、前記公開鍵検証手段により公開鍵が無効と判定された宛先への電子メールの送信を抑止する第２の抑止手段をさらに有する請求項５記載の電子メールシステム。
- ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、
前記メールサーバーが、
前記メールクライアントからの電子メールの暗号化機能に関する問合せに対し、自機が有する暗号化機能情報を応答する第１の応答手段を有し、
前記メールクライアントが、
前記メールサーバーに対して電子メールの暗号化機能に関する問い合わせを行う問合せ手段と、
前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、
前記公開鍵取得手段が取得した宛先の公開鍵の有効性を検証する公開鍵検証手段と、
前記公開鍵検証手段により公開鍵が有効であると判定された宛先の公開鍵を使って電子メールを暗号化する暗号化手段と、
前記問合せによりメールサーバーが電子メールの暗号化機能を有しないと判明した場合、前記暗号化手段により暗号化された電子メールと宛先情報を前記メールサーバーに送信する送信手段と、
を有することを特徴とする電子メールシステム。 - ネットワークを介して接続されたメールサーバーとメールクライアントとを含んで構成された電子メールシステムにおいて、
前記メールサーバーが、
前記メールクライアントから電子メール、宛先情報、及び前記電子メールを暗号化する旨の暗号化指示を受信する受信手段と、
前記宛先情報に含まれた各宛先の公開鍵を取得する公開鍵取得手段と、
前記受信手段が前記暗号化指示を受信した場合に、受信した電子メールを前記公開鍵取得手段が取得した各宛先の公開鍵を使って暗号化する暗号化手段と、
暗号化された電子メールを各宛先に送信する送信手段と、
前記公開鍵取得手段が取得した公開鍵の有効性を検証する公開鍵検証手段と、
前記公開鍵検証手段による公開鍵の有効性の検証結果に基づく通知を前記メールクライアントに対して行う検証結果通知手段と、
を有し、
前記メールクライアントが、
メールサーバーが取得した公開鍵の有効性の検証結果情報をメールサーバーから受信する検証結果受信手段と、
受信された検証結果情報に基づいて宛先を再設定する第２の宛先再設定手段と、
を有することを特徴とする電子メールシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001168425A JP3840919B2 (ja) | 2001-06-04 | 2001-06-04 | メールサーバー、メールクライアント及び電子メールシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001168425A JP3840919B2 (ja) | 2001-06-04 | 2001-06-04 | メールサーバー、メールクライアント及び電子メールシステム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006172767A Division JP2006287976A (ja) | 2006-06-22 | 2006-06-22 | メールサーバー、メールクライアント及び電子メールシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002368823A JP2002368823A (ja) | 2002-12-20 |
| JP3840919B2 true JP3840919B2 (ja) | 2006-11-01 |
Family
ID=19010656
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001168425A Expired - Lifetime JP3840919B2 (ja) | 2001-06-04 | 2001-06-04 | メールサーバー、メールクライアント及び電子メールシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3840919B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2003304620A1 (en) * | 2003-06-30 | 2005-01-21 | Net Agent, Co. Ltd. | Electronic mail transmission/reception system |
| JP2005203819A (ja) * | 2004-01-13 | 2005-07-28 | Hitachi Ltd | 電子署名検証システム |
| JP4595728B2 (ja) * | 2005-07-26 | 2010-12-08 | 富士ゼロックス株式会社 | 電子メール送信装置、プログラム、インターネットファックス送信装置、スキャン画像開示装置及び送信装置 |
| JP4917318B2 (ja) | 2006-01-31 | 2012-04-18 | 株式会社リコー | 通信装置、通信方法およびプログラム |
| JP2007318217A (ja) * | 2006-05-23 | 2007-12-06 | Fuji Xerox Co Ltd | 通信装置、方法およびプログラム |
| JP4519108B2 (ja) | 2006-06-22 | 2010-08-04 | コニカミノルタビジネステクノロジーズ株式会社 | 画像処理装置及びプログラム |
| JP5122877B2 (ja) * | 2006-10-04 | 2013-01-16 | 株式会社リコー | 通信装置 |
| JP5578221B2 (ja) * | 2006-10-04 | 2014-08-27 | 株式会社リコー | 通信装置、プログラム及び通信方法 |
| JP5030709B2 (ja) * | 2007-08-30 | 2012-09-19 | ソフトバンクモバイル株式会社 | 電子メールサーバー、電子メールシステム、電子メールプログラム及び電子メール処理方法 |
| JP2009130749A (ja) * | 2007-11-27 | 2009-06-11 | Hitachi Ltd | 電子メール暗号化システム |
| US20090217027A1 (en) * | 2008-02-21 | 2009-08-27 | Zenlok Corporation | Safe e-mail for everybody |
| JP4770961B2 (ja) | 2009-03-31 | 2011-09-14 | ブラザー工業株式会社 | 通信装置 |
| JP4770962B2 (ja) * | 2009-03-31 | 2011-09-14 | ブラザー工業株式会社 | 通信装置 |
| JP5736830B2 (ja) * | 2011-02-21 | 2015-06-17 | 日本電気株式会社 | メール送受信装置、プログラムならびに方法 |
-
2001
- 2001-06-04 JP JP2001168425A patent/JP3840919B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002368823A (ja) | 2002-12-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10313135B2 (en) | Secure instant messaging system | |
| US8166299B2 (en) | Secure messaging | |
| KR102660475B1 (ko) | 전자 신원확인 및 인증 서비스（ｅｉｄａｓ）를 위한 전자 계약을 인증하는 플랫폼 및 방법 | |
| US7930541B2 (en) | E-mail communication apparatus | |
| JP3840919B2 (ja) | メールサーバー、メールクライアント及び電子メールシステム | |
| EP1076298A2 (en) | Information transmitting apparatus, information saving apparatus, information receiving apparatus, method for using the same, and recording medium thereof | |
| CN102045267A (zh) | 消息召回的方法及装置 | |
| WO2005096543A1 (en) | Method of providing key containers | |
| US20160212093A1 (en) | System and method for smtp and alternative email protocol interoperability | |
| JP4367546B2 (ja) | メール中継装置 | |
| JP2012160110A (ja) | ファイル交換システム、ファイル交換サーバ、およびファイル交換プログラム | |
| EP1387239B1 (en) | Secure messaging | |
| KR20200077512A (ko) | 전자 신원확인 및 인증 서비스（ｅｉｄａｓ）를 위한 전자 공고를 인증하는 플랫폼 및 방법 | |
| JP4079928B2 (ja) | 電子ファイル配信装置および配信方法 | |
| JP2006287976A (ja) | メールサーバー、メールクライアント及び電子メールシステム | |
| KR101859580B1 (ko) | 대체형 이메일 전달 | |
| JP4055348B2 (ja) | 公開鍵取扱装置 | |
| WO2005053254A1 (en) | Secure message model | |
| JP4244987B2 (ja) | 電子メール処理装置 | |
| JP2007115279A (ja) | 電子メール装置 | |
| KR20070014350A (ko) | 푸시 프록시 게이트웨이와 콘텐츠 제공 서버에서의 인증방법 | |
| Maier | Automated Key Management for End-To-End Encrypted Email Communication | |
| JP2006025097A (ja) | 情報通信システム | |
| CA2531163A1 (en) | System and method for providing certified proof of delivery receipts for electronic mail |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040917 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060417 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060425 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060622 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060718 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060731 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3840919 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110818 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| EXPY | Cancellation because of completion of term |