(57)【特許請求の範囲】
【請求項１】
電子メール情報を管理するコンピュータに、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を実行させる電子メール情報管理プログラム。
【請求項２】
請求項１に記載の電子メール情報管理プログラムであって、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理プログラム。
【請求項３】
請求項１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
【請求項４】
電子メール情報を管理するための電子メール情報管理装置であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、
前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部と
を備える電子メール情報管理装置。
【請求項５】
電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報と、署名情報の時系列性を確保するための署名付加順序情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を備える電子メール情報管理方法。
【請求項６】
請求項５に記載の電子メール情報管理方法において、
前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、
前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする電子メール情報管理方法。
【請求項７】
請求項６に記載の電子メール情報管理方法において、
前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする電子メール情報管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メール情報を管理し、電子メール情報が正しく送られたものであることを容易に認証することができる電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法に関するものである。
【背景技術】
【０００２】
インターネット時代を迎え、電子メールは新しい社会基盤（インフラ）となっている。現在、電子メールは企業（ビジネス）や学校（教育）、知人へ私的連絡等、あらゆる場面でのコミュニケーションツールとして、欠かせない存在となっている。
【０００３】
電子メールの普及の背景として、送受信コストが既存手段よりも圧倒的に安価であることが挙げられ、電子メールを利用する情報機器も従来のPC（パソコン）環境のみならず、携帯電話やPDA（Personal Digital Assistant：携帯情報端末装置）等の移動端末にもメール機能が搭載され、電子メールは、近年、爆発的に利用・普及している電子情報と言える。
【０００４】
一方で、電子メールの内容保証に関する問題や、メールの大量配信（スパムメール）が社会問題にもなっている。この内容保証による対策として、S/MIME（Secure Multipurpose Internet Mail Extensions、電子メールの暗号化方式の標準）方式を用いる方法や、電子メール文書の原本性保証装置に関する技術が知られている（例えば下記特許文献１参照）。
【０００５】
具体的には、S/MIME方式では、メール本文に対して暗号化や電子署名を施すことにより、盗聴やなりすまし、改ざん等を防いでいる。また、特許文献１では、電子メールの本文とそれに添付されたファイルに対して、メール送信時に電子署名を付加し、メール受信時に改ざんの検知を行うための原本性保証装置を設け、該装置内に電子メールの本文と添付ファイルを暗号化して保存、更にアクセス制限をかけることで電子メールの機密性の要件を満たしている。
【０００６】
更に、迷惑メール対策として、一般的な文書の保存と同様、電子メールにも電子署名を用いて保証する事例が増えている。スパムメールとは、メール送信者が自分の身元を隠蔽するために、送信元に関する情報を詐称して送信されるもので、例えば、メールヘッダ中の差出人（From:メールアドレス部分）を他人のメールのヘッダ中からメールアドレスを引用し、あたかも自分の身元のように偽り送信するものである。
【０００７】
この対策として、近年、偽造メールアドレスの特定に焦点を当てたスパム対策技術（送信ドメイン認証技術）が開発されている。送信ドメイン認証技術には、IPアドレスを利用するものと、電子署名を利用するものの２種類があり、電子署名を利用するタイプの送信ドメイン認証の代表としては、DKIM（DomainKeys Identified Mail）という方式がある。
【０００８】
DKIM方式では、受信者側でメールを送信したサーバを特定したりチェックすることが可能である。具体的には、メールヘッダと本文を一括してSMTPサーバ（送信者側メールサーバ）の電子署名を生成し、その情報をDKIM-Signature:ヘッダとして追加する。
【０００９】
DKIM-Signature:ヘッダには、各種情報を格納する属性が存在し、主な属性としては、電子署名を付加した送信ドメインの名前を示すd属性（例: d=xx.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（例: a=rsa-sha1）、どの項目を署名対象にするかを示すh属性（例: h=From:To:Subject:Content-type）、送信ドメインによって生成された電子署名情報を格納するためのb属性（例: b=tfx8cgksw92）等がある。
【００１０】
以上のような属性を含むDKIM-Signature:ヘッダを追加後、受信者へ送信することで、受信者側では、そのDKIM-Signature:ヘッダの内容（各属性:電子署名等）を検証することにより送信されたメールサーバの特定が可能になるという仕組みである。
【００１１】
加えて、ヘッダと本文を一括して電子署名するため、ヘッダ（差出人（From））部分の引用等による詐称を防止することができ、安全なメール送信を実現することが可能である。現在、このような仕組みを持つDKIM方式に対して、複数の関連ベンダーによって標準化（RFC化）が急速に進められている。
【特許文献１】特開２００５−１０１８８３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、上述した S/MIME方式、特許文献１、DKIM方式の3つの従来技術に関する課題を以下に示す。
【００１３】
まず、S/MIME方式では、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報に関して電子署名を施すことはしていないため、スパムメールの対策にはなっていなかった。
【００１４】
特許文献１では、電子メール文書原本性保証装置にて電子メールを安全に管理することに注力している点、およびメール本文と添付ファイルを示す「コンテンツ情報」のみの保証に着眼したものである。従って、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報の変更や追加等がなされても、差出人（From）や件名（Subject）、メール本文の内容を個別に確認できるものではなかった。
【００１５】
DKIM方式では、メールヘッダの一部や本文（ボディ）の領域を自動的に変更するようなメーリングリスト（以降、MLと略）による同報メールには不向きであることが知られている。
【００１６】
メーリングリストとは、一群の読者にだけ送りたいメッセージを自動的に電子メールで届けることができるようにするための、電子メールアドレスのリストである。ある読者がリストに送ったメッセージは、すべて他の読者にも届く。メーリングリストに読者登録している人同士でメッセージを送ったり、それに返事をしたり、読んだりすることが可能である。
【００１７】
メーリングリストでは、MLアドレスで投稿されたメールは、一旦、MLサーバへ送られ処理される。この時、MLサーバは、電子署名の対象になる本文やヘッダを再配送する際に自動的に変更する場合が多く、投稿時に作成した電子署名が破壊されてしまい、受信者側で検証ができなくなってしまうという課題があった。
【００１８】
例えば、MLの名称とナンバリングをSubject:ヘッダに挿入することが多いため、DKIM をMLへ適用するには格段の注意が必要となっていた。
【００１９】
実際、標準化においてもMLへの適用は詳細に検討されており、例えば、MLのドメインにおいて送信ドメインの認証を行い、認証に成功した場合に、MLに関する新しいヘッダを追加した上で電子署名を生成し、DKIM-Signature:ヘッダを置き換える（つまり、先に格納された送信ドメインの電子署名を削除する）ことを推奨している。
【００２０】
この場合、送信ドメインの署名が削除されてしまうため、1つ手前の送信ドメイン認証しか行われない仕様となっており、どのような経路で配送されてきたか（送信元メールサーバの特定）の確認（送信から受信まで全ての経路認証）が行うことが不可能であった。
【００２１】
更に、無償でMLサーバを提供しているものの中には、メール本文（ボディ）の一部に広告を挿入するものもあり、従来のDKIMの仕様では、メール本文（ボディ）の書き換えに対応することができなかった。
【００２２】
本発明は、上述した課題を解決するためになされたものであり、電子メール、特に同報メール（例えば、メーリングリストで送信されるメール）に対する電子署名付加方法、および検証方法に関するものであり、送信ドメイン認証における経路認証、およびメール本文の内容保証を両立させて電子メール情報が正しく送られたことを容易に認証することができる電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法を得ることを目的とする。
【課題を解決するための手段】
【００２３】
上述した課題を解決するため、電子メール情報管理プログラムは、電子メール情報を管理するコンピュータに、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップとを実行させる。
【００２４】
また、電子メール情報を管理するための電子メール情報管理装置であって、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部とを備える。
【００２５】
また、電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップとを備える。
【００２６】
以上の態様において、前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップ又はヘッダ情報格納部は、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することができる。
【００２７】
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることができる。
【００２８】
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることができる。
【００２９】
また、前記情報取得ステップまたは前記情報取得部により取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることができる。
【００３０】
前記情報取得ステップまたは前記情報取得部により取得される前記署名対象情報は選択指定可能とすることができる。
【００３１】
また、電子メール情報管理方法において、前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする。
【００３２】
さらに、この電子メール情報管理方法において、前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする。
【００３３】
なお、本実施の形態においては、以下の項目が実行されている。
（１）電子情報のヘッダとボディに分割し、更に細かくヘッダ／ボディを項目毎に分割し、署名対象とする項目を決定する。
（２）決定した署名対象項目に対して、その内容の特徴量情報をそれぞれ算出する。
（３）事後、「誰が、どの項目を、どのように変更したか」の確認、および署名付加順序の正当性を担保するための情報を含む属性群を記録し、これら属性群に対する署名情報を生成・付加する。
（４）更に証明力を高めるため、生成した署名情報に対して、タイムスタンプ情報を付加してもよい。
（５）事後、「誰が、どの項目を、どのように変更したか」の確認、および署名付加順序の正当性を担保するための情報を含む属性群と生成した署名情報を内容とする署名ヘッダ情報を追加する。
【００３４】
（６）ヘッダ項目の一部、もしくはボディの変更が行われると、前記と同様の方法、記述により、新たな署名ヘッダ情報を生成・追加する。この時、先に記録されている署名ヘッダ情報は削除せず、上書きされない版数管理を行う。
（７）検証時には、ヘッダに付加された全ての署名ヘッダ情報の内容を検証することで、「誰が、どの項目を、どのように変更したか」を確認することが可能である。追記されている署名ヘッダ情報の順序の正当性については、各署名ヘッダ情報内に記録された署名付加順序の正当性を担保するための情報で確認することが可能である。
（８）ボディの書き換え時には、本文領域と添付領域を識別する項目を確認することで、それぞれの特徴値の算出・記録を行う。
【発明の効果】
【００３５】
本発明によれば、送信元メールサーバの正当性確認とメールコンテンツ（差出人、宛先、件名、本文等を含む）の内容保証を両立させることが可能になる。最終的な受信側において、具体的には、どのような経路を辿って配送されてきたか（送信元メールサーバの特定）確認（経路情報）が可能で、かつ配送過程でヘッダ情報や本文情報を変更・追加されても、項目単位で確認することが可能で、その操作事実の正当性証明を第三者に行うことが可能である。
その結果、受信者は、送信者、経路情報、変更・追加等の操作を項目単位で確認できるようになるため、安心してメールを受信したり閲覧することが可能となる。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施の形態を図を用いて説明する。
【００３７】
実施の形態１．
図１は、本発明の原理を示すブロック説明図である。図２は、その処理フローチャートを示している。
【００３８】
図２に示す全体動作は、電子メール情報１が作成され、他のネットワーク系へ送信する場合に開始される。まず、差出人（From）、宛先（To）、件名（Subject）等を含むヘッダ情報１ａと、メール本文の内容を表す本文情報１ｂに区分し（ＳＴ−１）、更にヘッダ情報１ａは、事後、原本保証（内容保証）を必要対象としない署名非対象ヘッダ情報群１ａ−１と、必要対象とする署名対象ヘッダ情報群１ａ−２に分離、区分される。本文情報はその内容により適宜本文情報１〜Ｎに区分される。
【００３９】
また、MIME（Multipurpose Internet Mail Extensions）-multipartメールの場合、各本文情報を区別可能な識別子の参照により、各本文情報の区分が行われる（ＳＴ−２）。
【００４０】
ここで、分離・区分された前記署名対象ヘッダ情報群に対する特徴量情報１０ａを生成するヘッダ情報特徴量生成部１０（ＳＴ−３）と本文情報群の特徴量情報２０ｂを生成する本文情報特徴量生成部２０（ＳＴ−４）を備える。
【００４１】
更に、前記署名対象ヘッダ情報群の特徴量情報、および本文情報群の特徴量情報を一体化し、署名対象ヘッダ情報群および本文情報の特徴量情報２ａを生成する特徴量集合生成部３０−１と、署名付加順序の正当性を担保するための情報２ｂを取得し付加する署名付加順序情報取得部３０−２と、署名情報２ｃを生成し付加する署名情報生成部３０−３とを備える。
【００４２】
そして、署名関連情報２ｄ、署名対象ヘッダおよび本文情報２ｅ、署名対象ヘッダ情報群および本文情報２ｆ、及びそれらの特徴量情報２ａ、署名付加順序情報２ｂ、これら内容に対する署名者の「署名情報」を付加した署名ヘッダ情報２の生成を行う署名ヘッダ情報生成部３０が備えられる（ＳＴ−５）。署名ヘッダ情報２は、署名ヘッダ情報格納部４０によって、電子メール情報１内のヘッダ情報内に追記・格納される（ＳＴ−６）。
【００４３】
そして、この電子メールが配送経路中に他のネットワーク（第２ネットワーク）へ配送されるごとに、上記動作が繰り返される。このとき先に格納した署名ヘッダ情報２は上書きされず、版数管理により追記されて格納される。
【００４４】
そして、この電子メールが他のネットワーク（異なるドメイン名を有するネットワーク）で受信されると（ＳＴ-７）、後述するように署名ヘッダ情報の検証が行われ（ＳＴ−８）、更に他のネットワーク（第３ネットワーク）に送信される場合（例えば同報メール送信の場合）（ＳＴ−９，ＹＥＳ）、ステップＳＴ−２に戻り、上述したと、同様に第２ネットワークにおいて、再度ヘッダ情報特徴量生成部１０、本文情報特徴量生成部２０、署名ヘッダ情報生成部３０を用いて新たな署名ヘッダ情報２が生成され、署名ヘッダ情報格納部４０によって、電子メール情報１内のヘッダ情報内に追記・格納される。この時、先に格納した署名ヘッダ情報２は上書きされず、版数管理により順次格納されて記録がなされていく。
【００４５】
上述した署名ヘッダ情報の検証処理（ＳＴ−８）においては、格納された署名ヘッダ情報２が改ざんされていないことの検証を行う機能を有する署名ヘッダ情報改ざん検証部５０−１を備え、また、電子メール情報１内のヘッダ情報、および本文情報から特徴量情報を生成し、署名ヘッダ情報２に格納された該特徴量情報と比較を行い、変更有無の確認を行う機能を有する項目特徴量情報検証部５０−２を備え、更に、検証対象となるすべての署名ヘッダ情報２を比較・検証し、項目毎に変更有無の確認を行う機能を有する署名ヘッダ情報検証部５０−３（ＳＴ−８）を備える電子情報検証部５０を備える。
【００４６】
本実施の形態の詳細な一例を示すために、図３のような登場エンティティ、メール配送環境を設定し、ユーザＡ（送信者）から送られた同報メールが、ドメイン１（第１ネットワーク系）からドメイン３（第３ネットワーク系）を経由してユーザＢ（受信者）までメール配送されるシーンを想定して説明する。
【００４７】
具体的には、ユーザＡ（送信者）により、「差出人（From）：userA@xx.com」、「宛先（To）：ml@zz.com」、「件名（Subject）：hello」を含むヘッダ情報を、メール本文情報として、「こんにちは、お元気ですか」という内容のメッセージを記載する場面を想定して同報メールが送信され、ユーザＢ（受信者）により、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認が行われる場面を想定する。
【００４８】
同報メール（ml@zz.com）はユーザＢ（受信者）も閲覧・受信できる状況となっていることを前提とする。また、ドメイン２のMLサーバによるヘッダ情報の追加・変更が行われる事例として、第１の実施の形態では、件名（Subject）のみが書き換わる場面、第２の実施の形態では、件名（Subject）が書き換わり、本文への広告追加が行われる場面の２つの実施形態例を採り上げて説明する。
【００４９】
第１の実施の形態．
まず、第１の実施形態として、ドメイン２のMLサーバにより、件名（Subject）のみが書き換わる場面を想定して説明する。なお、本実施形態では、メール情報中のすべての項目を署名対象とすることを前提に説明する。
【００５０】
図４は、第１の実施形態におけるＳＭＴＰサーバ１による署名付加の様子を示している。
【００５１】
ユーザＡ（送信者）により、メール作成、およびメール送信の実行ボタンを押下されると、まず、SMTPサーバ１により、ヘッダ情報と本文情報の区分（ＳＴ-ＳＭＴＰ１−１）、および署名対象のヘッダ情報群と本文情報の抽出（ＳＴ-ＳＭＴＰ１−２）が行われる。本例の場合、メール情報中のすべての項目を署名対象とすることを前提にしているため、署名対象ヘッダ情報群は、差出人（From）、宛先（To）、件名（Subject）、本文情報（Content-Type）とする。この選択は、あらかじめメールシステム内で定義されるか、送信者自身が保証したい項目を指定し、選択することで実現できる。
【００５２】
次に、ＳＴ-ＳＭＴＰ１−２で抽出された署名対象ヘッダ情報群の特徴量情報の生成（ＳＴ-ＳＭＴＰ１−３）、および本文情報の特徴量情報の生成（ＳＴ-ＳＭＴＰ１−４）を行う。
【００５３】
続けて、署名対象ヘッダ情報群の特徴量情報と本文情報の特徴量情報を一体化し、署名ヘッダ情報（PIAT-Signature:ヘッダ）の属性値として記録する（ＳＴ-ＳＭＴＰ１−５−１）。本例では、From:ヘッダの特徴量として、“0xf81dca2e22”が、To:ヘッダの特徴量として、“0x31dca9ba12”が、Subject:ヘッダの特徴量として、“0x5243cd2a8b”が、Content-Type:ヘッダの特徴量として、“0xf91d38aac1”がそれぞれ算出されている様子を示している。
【００５４】
また、一体化することの一例として、署名対象ヘッダを格納するためのh属性（h:属性タグ）を設け、該属性内にコロン（:）を境界として署名対象としてヘッダ情報を格納して列挙する。
【００５５】
更に、署名対象ヘッダ情報群、および本文情報の特徴量情報を格納するためのh-hash属性を設け、h属性同様、該属性内にコロン（:）を境界として各特徴量を格納し、列挙する。
【００５６】
これにより、それぞれのヘッダに格納される情報の順序を統一的に対応付けることが可能となる。PIAT-Signature:ヘッダのその他の属性としては、署名関連情報の属性として、署名を行ったドメイン名（ネットワーク情報）を格納するためのｄ属性（d：属性タグ）（例: d=xx.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（ａ：属性タグ）（例: a=rsa-sha1）等があり、本例では、d属性、およびa属性が記録される様子を示している。
【００５７】
a属性で署名の生成に利用したアルゴリズムを格納することにより、事後確認を行い、その正当性を判断できるようにしている。これにより、次回以降の署名生成時、および検証時で使用する署名アルゴリズムを容易に検索可能となる。
【００５８】
更に、オリジナルのヘッダ情報、および本文情報を格納するためのh-org属性、署名付加順序の正当性を担保するための情報（いわゆる、署名情報の時系列性を確保するための情報）を格納するt属性（ｔ:属性タグ）（例: t=20070801154256）を記録している。
【００５９】
t属性は予め署名付加順序情報を取得し、本例では日時情報を用いており、2007年8月1日15時42分56秒が格納されている様子を示している（ＳＴ-ＳＭＴＰ１−５−２）。
【００６０】
なお、日時情報を用いる場合、日時の改変が不可能な第三者機関が発行する正当な情報が取得できることが望まれることは容易に推測できる。日時情報の他に、１から順に加算していく、インクリメンタルカウンタ方式を用いてもよい。
【００６１】
以上の各属性の格納が完了すると、続けて、署名ヘッダ情報全体を対象とし、署名情報の生成を行う（ＳＴ-ＳＭＴＰ１−５−３）。本例では、PIAT-Signature:ヘッダの内容すべて（「PIAT-Signature:〜t=20070801154256;」）を署名対象としてハッシュ値を生成し、更に、SMTPサーバ１の秘密鍵を用いて署名情報を生成し、該署名情報を格納するためのb属性を設け、該属性に生成した署名情報を格納している。
【００６２】
ここで、秘密鍵を用いて署名情報の生成を行うには、予めSMTPサーバ１内にて、秘密鍵と公開鍵のペアを生成しておき、署名情報の生成時には本秘密鍵を用いる。ペアとなる公開鍵はSMTPサーバ１上で公開し、受信側にて取得できるようにしておく。
【００６３】
図４では、PIAT-Signature:ヘッダの最後の属性として、b=8ffkadalo1lRDI2jsdl82が格納されている様子を示している。このように、PIAT-Signature:ヘッダ（本例では、b属性:署名情報部分は含まない）を署名対象とすることにより、該署名を付加したドメイン以外がPIAT-Signature:ヘッダを変更させない仕組みとすることができ、PIAT-Signature:ヘッダの改ざん防止対策とすることができる。
【００６４】
更に署名情報の他に、確定時刻を保証するための技術である、タイムスタンプを利用し、付加することにより証明力を高めることも可能であるが、本例では必ずしもタイムスタンプの付加は必須としていない。
【００６５】
また、本例では、h-org属性を設け、オリジナルのヘッダ情報、および本文情報を格納している。
【００６６】
本属性にオリジナルの内容が格納されていない場合、事後配送過程で変更がなされた場合、変更の事実は確認できるが、どのような状態から変更が行われたかの確認を行うことができない。その確認を可能とするためにh-org属性を設けているが、少なくとも、本文情報に関しては、情報量が大きくなる可能性が高いため、該情報をヘッダ中に格納としておくのは、情報量の膨大の観点から、更に安全性の観点からあまり好ましくない。格納するか否かの選択は管轄するSMTPサーバのポリシーに従う、および検証サービスの充実度に影響するものとし、このh-org属性はオプション的役割を持つことをひとつ付け加えておく。
【００６７】
SMTPサーバ１による署名ヘッダ情報の生成が完了すると、署名ヘッダ情報格納部４０によって、電子メール情報のヘッダ内に該情報が格納される（ＳＴ-ＳＭＴＰ１−６）。
【００６８】
本実施形態では、署名ヘッダ情報をヘッダ情報の一部として、ヘッダ情報内に格納したが、別サーバで一括管理する方法もあり得る。その場合、どのメールに対する署名ヘッダ情報かを別に管理する必要が生じるため、該電子メール情報のヘッダ情報内に順次格納され、配送されていくのが望ましい。
【００６９】
SMTPサーバ１による署名ヘッダ情報の生成が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ１からドメイン２のPOPサーバ１に対してメールが送信される。
【００７０】
図５は、ドメイン２内のPOPサーバ１における署名検証処理の様子を示している。まず、SMTPサーバ１からの正しい送信情報であることを確認するため、署名ヘッダ情報に付加されたPIAT-Signature:ヘッダの検証を行う。
【００７１】
具体的には、まず、署名情報の生成時に使われた秘密鍵に対する公開鍵をSMTPサーバ１から取得する。このSMTPサーバ１の取得情報は、PIAT-Signature:ヘッダ内に格納されている必要があることは容易に推測できる。続けて、PIAT-Signature:ヘッダ（本例では署名情報を示すb属性は含まない）の内容からハッシュ値を生成し、署名情報を生成する（ＳＴ−ＰＯＰ１−１）。ここで署名情報の生成アルゴリズムには、a属性に格納されている、rsa-sha1を用いる。
【００７２】
次に、先に取得した公開鍵を利用して、PIAT-Signature:ヘッダ内のb属性に格納された署名情報からハッシュ値を取り出し、受信した電子メール情報から生成したハッシュ値を比較する（ＳＴ−ＰＯＰ１−２）。
【００７３】
これは、署名ヘッダ情報改ざん検証部５０−１を用いて比較が可能である。これらハッシュ値が同じであれば検証（認証）成功となる。次の配送先に検証に成功したことを示すため、検証結果を格納するヘッダを追加してもよい。ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザＡ（送信者）に対してその旨、通知を行う。
【００７４】
正しい送信情報であることが確認できれば、宛先（To）: ml@zz.comが指定された同報メールは、一旦、管理するMLサーバへ送信される。該同報メールを受信したMLサーバは、ヘッダ情報中の件名（Subject）にMLの項番を表す“[ml:001]”を元の件名の前に追加する（ＳＴ−ＭＬ−１）。
【００７５】
図６は、件名（Subject）にMLの項番を表す“[ml:001]”が追加された様子を示している。この行為は、MLサーバがヘッダ情報を変更する一般的な（標準的な）動作である。件名（Subject）を変更したMLサーバはSMTPサーバ２に対して、該電子メール情報を送信する。
【００７６】
図７は、本実施形態におけるＳＭＴＰサーバ２による署名付加の様子を示している。まず、SMTPサーバ２における署名対象ヘッダ情報群抽出のための項目選択に関して、SMTPサーバ１の署名ヘッダ情報内を参照し、どの項目が署名対象となっているかの確認、および署名情報の生成方法に関する情報を取得する（ＳＴ−ＳＭＴＰ２−１）。
【００７７】
本例の場合、h属性に格納された情報から、差出人（From）、宛先（To）、件名（Subject）、本文情報（Content-Type）が署名対象であることが確認でき、a属性に格納された情報から、署名情報の生成方法（生成アルゴリズム）として、rsa-sha1を使用して生成することが確認できる。次に、確認した署名対象ヘッダ情報群の特徴量情報の生成（ＳＴ−ＳＭＴＰ２−２）、および本文情報の特徴量情報の生成（ＳＴ−ＳＭＴＰ２−３）を行う。
【００７８】
続けて、署名対象ヘッダ情報群の特徴量情報と本文情報の特徴量情報を一体化し、署名ヘッダ情報（PIAT-Signature:ヘッダ）の属性値として記録する（ＳＴ−ＳＭＴＰ２−４−１）。
【００７９】
本例では、From:ヘッダの特徴量として、“0xf81dca2e22”が、To:ヘッダの特徴量として、“0x31dca9ba12”が、Subject:ヘッダの特徴量として、“0xa8bdc1238c”が、Content-Type:ヘッダの特徴量として、“0xf91d38aac1”がそれぞれ算出されている様子を示している。
【００８０】
PIAT-Signature:ヘッダのその他の属性としては、署名関連情報の属性として、署名を行ったドメイン名を格納するためのd属性（例: d=zz.com）、署名の生成に利用したアルゴリズムを格納するためのa属性（例: a=rsa-sha1）等がある。
【００８１】
ここで、d属性はSMTPサーバ１と違い、SMTPサーバ２のドメイン名が格納され、a属性はそのまま継承される。更に、オリジナルのヘッダ情報、および本文情報を格納するためのh-org属性、署名付加順序の正当性を担保するための情報（いわゆる、署名情報の時系列性を確保するための情報）を格納するt属性（例: t=20070801154501）も同様に記録している（ＳＴ−ＳＭＴＰ２−４−２）。
【００８２】
以上の各属性の格納が完了すると、続けて、署名ヘッダ情報全体を対象とし、署名情報の生成を行う（ＳＴ−ＳＭＴＰ２−４−３）。本例では、PIAT-Signature:ヘッダの内容すべて（「PIAT-Signature:〜t=20070801154501;」）を署名対象としてハッシュ値を生成し、更に、SMTPサーバ２の秘密鍵を用いて署名情報を生成し、該署名情報を格納するためのb属性を設け、該属性に生成した署名情報を格納している。
【００８３】
ここで、秘密鍵を用いて署名情報の生成を行うには、予めSMTPサーバ２内にて、秘密鍵と公開鍵のペアを生成しておき、署名情報の生成時には本秘密鍵を用いる。ペアとなる公開鍵はSMTPサーバ２上で公開し、受信側にて取得できるようにしておく。
【００８４】
図７では、PIAT-Signature:ヘッダの最後の属性として、b=jf987a3bdFHaiq13291bdが格納されている様子を示している。このように、PIAT-Signature:ヘッダ（本例では、b属性:署名情報部分は含まない）を署名対象とすることにより、該署名を付加したドメイン以外がPIAT-Signature:ヘッダを変更させない仕組みとすることができ、PIAT-Signature:ヘッダの改ざん防止対策とすることができる。更に署名情報の他に、確定時刻を保証するための技術である、タイムスタンプを利用・付加することにより証明力を高めることも可能であるが、本例では必ずしもタイムスタンプの付加は必須としていない。
【００８５】
SMTPサーバ２による署名ヘッダ情報の生成が完了すると、署名ヘッダ情報格納部４０によって、電子メール情報のヘッダ内に該情報が格納される（ＳＴ−ＳＭＴＰ２−５）。
【００８６】
この時、ヘッダ情報内には、SMTPサーバ１の署名ヘッダ情報が格納されているため、先に格納された該署名ヘッダ情報は上書きされず、版数管理により順次格納し記録がなされていく。また先に格納されたSMTPサーバ１の署名ヘッダ情報との時系列性に関しては、署名ヘッダ情報内に記録されたt属性にて事後確認可能である。
【００８７】
各t属性は、それを包含した署名情報の検証により、その正当性が担保されれば、本時系列性についても同様に正当性を確保することが可能となる。また、署名情報に対して、タイムスタンプが付加されているならば、該情報でも事後確認可能である。
【００８８】
SMTPサーバ２による署名付加が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ２からドメイン３のPOPサーバ２に対してメールが送信される。
【００８９】
図８は、ドメイン３内のPOPサーバ２における署名検証処理の様子を示している。まず、SMTPサーバ１、およびSMTPサーバ２からの正しい送信情報であることを確認するため、署名ヘッダ情報に付加されたPIAT-Signature:ヘッダの検証を行う。
【００９０】
具体的には、まず、署名情報の生成時に使われた秘密鍵に対する公開鍵をSMTPサーバ１、およびSMTPサーバ２からそれぞれ取得する。続けて、PIAT-Signature:ヘッダ（本例では署名情報を示すb属性は含まない）の内容からハッシュ値を生成し、署名情報を生成する（ＳＴ−ＰＯＰ２−１）。
【００９１】
ここで署名情報の生成には、各a属性に格納されている、rsa-sha1を用いる。次に、先に取得した公開鍵を利用して、PIAT-Signature:ヘッダ内のb属性に格納された署名情報からハッシュ値を取り出し、受信した電子メール情報から生成したハッシュ値を比較する（ＳＴ−ＰＯＰ２−２）。
【００９２】
これは、署名ヘッダ情報改ざん検証部５０−１を用いて比較が可能である。これらハッシュ値が同じであれば検証（認証）成功となる。次の配送先に検証に成功したことを示すため、検証結果を格納するヘッダを追加してもよい。ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザＢ（受信者）に対してその旨、通知を行う。
【００９３】
正しい送信情報であることが確認できれば、続けて、各ヘッダ情報、および本文情報の内容を取り出し、ヘッダ情報特徴量生成部１０、および本文情報特徴量生成部２０を用いて、各ヘッダ情報、および本文情報の特徴量を生成し、SMTPサーバ２の署名ヘッダ情報のh-hash属性に記録された各ヘッダ情報、および本文情報の特徴量と比較を行う（ＳＴ−ＰＯＰ２−３、ＳＴ−ＰＯＰ２−４）。
【００９４】
図９は、その検証の様子を示している。具体的には、From:ヘッダの“userA@xx.com”からヘッダ情報特徴量生成部１０を用いて、From:ヘッダの特徴量を生成し（ＳＴ−ＰＯＰ２−３）、SMTPサーバ２の署名ヘッダ情報のh-hash属性に記録されているFrom:ヘッダの特徴量（“0xf81dca2e22”）と比較を行う（ＳＴ−ＰＯＰ２−４）。
【００９５】
これは、項目特徴量情報検証部５０−２を用いて比較が可能である。続けて、To:ヘッダ、Subject:ヘッダ、Content-Type（本文情報）も同様の方法で比較を行い、同一かどうか確認する。上記比較の結果、異なる場合は、途中なんらかの改変が行われていることを示しているため、ユーザＢ（受信者）に対してその旨、通知を行う。
【００９６】
同一であれば、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報の各特徴量情報の比較及び検証を行う。
【００９７】
図１０は、その検証の様子を示している。具体的には、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報のh-hash属性を確認し、署名ヘッダ情報検証部５０−３を用いて、それぞれの署名対象ヘッダ情報、および本文情報の特徴量を比較する（ＳＴ−ＰＯＰ２−５）。
【００９８】
例えば、h-hash属性の一番初めに記録されている“0xf81dca2e22”は、From:ヘッダの特徴量である。一番初めに記録されているのがFrom:ヘッダであることを確認するには、h属性を確認すればわかる。From:ヘッダの場合、SMTPサーバ1の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報共に“0xf81dca2e22”が記録されており、同一のため、From:ヘッダは、SMTPサーバ1の時点から変更が加えられていないことを確認できる。
【００９９】
同様に、To:ヘッダも共に“0x31dca9ba12”で同一で変更なし、Content-Type（本文情報）についても共に“0xf91d38aac1”で同一で変更がないことを確認できる。一方、Subject:ヘッダにおいては、SMTPサーバ1のSubject:ヘッダの特徴量は、“0x5243cd2a8b”で、SMTPサーバ２のSubject:ヘッダの特徴量は、“0xa8bdc1238c”で異なる値が格納されている。これは、唯一、配送経路途中で変更となったヘッダ情報であることを示しており、かつ該署名ヘッダ情報内のb属性（SMTPサーバ２の署名情報）からSMTPサーバ２により変更がなされたことを確認できる。
【０１００】
更に、SMTPサーバ１の署名ヘッダ情報、およびSMTPサーバ２の署名ヘッダ情報の各h-org属性内のSubject:ヘッダ部分を確認すれば、どのように変更がなされたかも確認できる。
【０１０１】
本例では、“hello”から“[ml:001] hello”に変更がなされたことが確認できる。h-org属性はこのために利用するものであり、記録を行うことでより検証サービスの充実度を向上させることが可能となる。
【０１０２】
以上の比較・検証の結果をまとめると、POPサーバ２は、ユーザＢ（受信者）に対して、（１）SMTPサーバ１からSMTPサーバ２の経路を辿って配送されてきたこと、（２）SMTPサーバ２が、件名（Subject）に対して[ml001]を追加したこと、（３）差出人（From）、宛先（To）、本文情報（Content-Type）の内容は配送中、変更が加えられていないことを通知可能となる。
【０１０３】
このように第１の実施形態では、すべてのヘッダ情報、および本文情報に関して特徴量を記録、署名ヘッダ情報を追加していくことで、上記のような検証をユーザＢ（受信者）で行うことが可能となる。
【０１０４】
第２の実施形態．
続けて、第２の実施形態では、本文情報への追加が伴う事象について採り上げ、特に件名（Subject）が書き換わり、本文情報への広告追加が行われる場面を想定して説明する。
【０１０５】
本文情報への広告が追加される場合の一例として、例えば、無償でMLサーバを提供しているものの中には、メール本文（ボディ）の一部に広告を挿入するものもある。
【０１０６】
また、複数の本文情報を持ち、各本文情報を区別可能な識別子を有するものとしての代表例として、MIME-multipartメールがある。
【０１０７】
MIME-multipartとは、一通の電子メールに複数の異なる種類のデータを格納する方式で、電子メールにASCII文字以外のデータを格納するための「MIME」規格の拡張仕様である。インターネットの技術仕様の標準化にあたっているIETF（Internet Engineering Task Force）により、RFC 2112として規格化されている。添付ファイルとして画像を送ったりするのに使われる。
【０１０８】
従来、電子メールはヘッダ情報と本文情報という2つの部分しか持てなかったが、multipart仕様により、「区切り文字」を境に任意の数の部分（パート）に分割することが可能となった。これにより、例えば1つの電子メールに本文、画像、ワープロ文書、音声をまとめて送受信することができる。
【０１０９】
MIME-multipartメールには、Content-Type:ヘッダが設けられ、「メディアタイプ」と呼ばれる本文情報（ボディ）部分の属性を示すヘッダ情報がある。
【０１１０】
図１１は、MIME-multipartメールの一例を示している。まず、ヘッダ情報で、multipartであることを宣言おり（図１１中、MIME-1）、ヘッダ情報と本文情報の境界には、空行（CR（0x0d）+LF（0x0a）のみの行））が存在する（図１１中、MIME-2）。
【０１１１】
本文情報は、複数の「MIMEヘッダ情報＋本文情報」から構成される「ミニ・メッセージ」、すなわち「パート」になっている（図１１中、MIME-4）。同様に、MIMEヘッダ情報と本文情報の境界には、空行が存在する。この「ミニ・メッセージ」、すなわち「パート」が１つの添付ファイルやメール本文に該当する。
【０１１２】
多くのメーラーでは、メール本文にテキストを記載してファイルを添付すると、このmultipart形式となる。１つのパートの境界は、「バウンダリ：boundary」と呼ばれる任意の文字列の行で示される（図１１中、MIME-3）。これはContent-Type:ヘッダのboundaryパラメータで、あらかじめヘッダに示されている（図１１中、MIME-6）。
【０１１３】
図１１中、MIME-3で示される、「--boundary_str」は、これで、1つのパートの開始を示している。また、図１１中、MIME-5で示される、「--boundary_str--」は、全体のmultipartの終了を示している。
【０１１４】
次に、このMIME-multipartメールを想定した署名ヘッダ情報の生成方法について説明する。図１２は、本実施形態におけるＳＭＴＰサーバ1による署名付加の様子を示している。署名ヘッダ情報の生成方法は、図４の手順で示したとおりであり、ここでは説明を割愛するが、本文情報（Content-Type）の特徴量は、本文情報内の「MIMEヘッダ+本文情報」、つまり、“--boundary_str〜こんにちは、お元気ですか”を対象として、本文情報特徴量生成部２０を用いて生成されていることを付け加えておく。
【０１１５】
更に、図１３では、本実施形態におけるＳＭＴＰサーバ２による署名付加の様子を示している。これは、先に説明のとおり、ドメイン２内のMLサーバにより、Subject:ヘッダを変更し、本文情報に広告（“安心と安全の○△プロバイダ”という内容）を追加した場面を想定しており、これも署名ヘッダ情報の生成方法については、図７の手順で示したとおりであり、ここでは説明を割愛するが、本文情報（Content-Type）の特徴量は、本文情報内の「MIMEヘッダ+本文情報」、つまり、“--boundary_str〜安心と安全の○△プロバイダ”を対象として、本文情報特徴量生成部２０を用いて生成されていることを付け加えておく。
【０１１６】
また、SMTPサーバ２が付加した署名ヘッダ情報内のh属性の最後に、本文情報を示すContent-Typeが追加され、同様に、h-hash属性の最後にも、本文情報（広告）の内容に対する特徴量が格納される。
【０１１７】
検証時には、図９で示したとおり、各本文情報から本文情報特徴量生成部２０を用いて特徴量を生成し、h-hash属性に格納されている該特徴量と比較することで確認を行っていたが、図１３で示した例の場合、h属性に格納された本文情報を示す名前が共に“Content-Type”であるため、h-hash属性に格納された各特徴量は、どの本文情報に対する特徴量なのか識別することができない。
【０１１８】
図１３で示した例の場合では、まず、送信者（SMTPサーバ１）によって、本文情報が記録され、それを受信したMLサーバ（SMTPサーバ２）は続けて、広告を示す本文情報を送信者が記録した本文情報より後に追記することを前提にすれば、最初のContent-Typeは、送信者（SMTPサーバ１）が記録した情報、2つ目のContent-Typeは、MLサーバ（SMTPサーバ２）が記録した情報と認識することが可能である。
【０１１９】
また、別の手段では、図９で説明したとおり、本文情報から本文情報特徴量生成部２０を用いて特徴量を生成し、h-hash属性に格納されている該特徴量と比較し、一致することを確認することで、どちらの本文情報の特徴量かを判断することが可能である。
【０１２０】
更に、図１０で説明したとおり、SMTPサーバ１が付加した署名ヘッダ情報と、SMTPサーバ２が付加した署名ヘッダ情報を参照し、署名ヘッダ情報検証部５０−３を用いて各特徴量を比較することで、追加となった本文情報（広告）の特徴量は、SMTPサーバ１の署名ヘッダ情報には存在せず、SMTPサーバ２の署名ヘッダ情報に新たに追加されていることが確認できるため、追加された特徴量は、本文情報（広告）であることを判断することが可能である。
【０１２１】
更に、別の手段として、図１４で示すように、本文情報内の「MIMEヘッダ」に、本文情報の内容を示す“X-Content-Type-body”、“X-Content-Type-Advertisement”のように識別する情報を追加し、署名ヘッダ情報内のh属性にも該情報を示す内容を格納することで、各本文情報の特徴量を容易に識別・確認することが可能である。
【０１２２】
この“X-”が先頭に付くヘッダ情報は、SMTPサーバ１、およびMLサーバが独自につける項目であることを示している。
【０１２３】
本例の場合、共に“Content-Type: text/plain; charset="ISO-2022-JP"”であることを想定したが、当然、画像ファイル（例:GIFファイル）が添付される場合の構文は、“Content-Type image/gif”になるため、“X-Content-Type-body”のような追加による識別は必要ない。ただし、例えば、画像ファイルが添付されているメールの場合においては、署名ヘッダ情報内のh属性に格納する内容は、“Content-Type”だけでなく、“Content-Type image/gif”のような形式で記録されていることが望ましい。この場合、同様に、画像ファイルが2つ添付されているような場合、“Content-Type image/gif”だけでは識別できない可能性があるため、“X-Content-Type-gif1”、“X-Content-Type-gif2”のような書き方がより適切である。
【０１２４】
上述した本発明の実施の形態において、各フローチャートに示したステップを電子メール情報管理プログラムとして、コンピュータにより読取り可能な記録媒体に記憶させることによって、構造解析方法をコンピュータに実行させることが可能となる。なお、本発明において、上記コンピュータにより読取り可能な記録媒体は、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
【０１２５】
以上に詳述した実施の形態において、更に下記付記が追記される。
（付記１）
電子メール情報を管理するコンピュータに、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を実行させる電子メール情報管理プログラム。
（付記２）
付記１に記載の電子メール情報管理プログラムであって、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理プログラム。
（付記３）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記４）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記５）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理プログラム。
（付記６）
付記１に記載の電子メール情報管理プログラムにおいて、
前記情報取得ステップにより取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理プログラム。
（付記７）
電子メール情報を管理するための電子メール情報管理装置であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得部と、
前記情報取得部により取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成部と、
前記情報取得部により取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報と、前記電子署名データ生成部により生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納部と
を備える電子メール情報管理装置。
（付記８）
付記７に記載の電子メール情報管理装置において、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納部は前記電子メールのヘッダ部に前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理装置。
（付記９）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１０）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１１）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理装置。
（付記１２）
付記７に記載の電子メール情報管理装置において、
前記情報取得部により取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理装置。
（付記１３）
電子メール情報を管理するコンピュータにより行われる電子メール情報管理方法であって、
メールヘッダとメール本文とから所定の複数の情報を取得すると共に、これら複数の情報に関連するネットワーク情報を含む情報を署名関連情報として取得し、これら情報をそれぞれの属性を示す属性タグに対応付けて署名対象情報として取得する情報取得ステップと、
前記情報取得ステップにより取得された前記署名対象情報のそれぞれについて特徴量情報を生成し、特徴量情報を示す属性タグに対応付けて取得する特徴量情報生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成部により生成された前記特徴量情報との全体に対して電子署名を行って電子署名データを生成し、電子署名データを示す属性タグに対応付けて取得する電子署名データ生成ステップと、
前記情報取得ステップにより取得された前記署名対象情報と、前記特徴量情報生成ステップにより生成された前記特徴量情報と、前記電子署名データ生成ステップにより生成された電子署名データとを、それぞれの前記属性タグに対応付けて前記電子メールのヘッダ部に署名ヘッダ情報として格納するヘッダ情報格納ステップと
を備える電子メール情報管理方法。
（付記１４）
付記１３に記載の電子メール情報管理方法において、
前記電子メールが他のネットワークから受信された場合に、前記ヘッダ情報格納ステップは、前記電子メールのヘッダ部に前記他のネットワークにおいて既に格納されているヘッダ情報に対し、前記署名ヘッダ情報を追加的に格納することを特徴とする電子メール情報管理方法。
（付記１５）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、前記電子メール情報のオリジナル情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１６）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、前記電子署名に使用したアルゴリズムがそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１７）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される署名関連情報には、署名情報作成時の時間情報がそれを示す属性タグとともに含まれることを特徴とする電子メール情報管理方法。
（付記１８）
付記１３に記載の電子メール情報管理方法において、
前記情報取得ステップにより取得される前記署名対象情報は選択指定可能であることを特徴とする電子メール情報管理方法。
（付記１９）
付記１３に記載の電子メール情報管理方法において、
前記電子メールが他のネットワークに送信され、該他のネットワークにおいて受信された場合に、
前記他のネットワーク系内において、前記署名ヘッダ情報に基づいて、該電子メールの検証を行う検証ステップが備えられることを特徴とする電子メール情報管理方法。
（付記２０）
付記１９に記載の電子メール情報管理方法において、
前記検証ステップの結果、該電子メールが正当なものと判断された場合、前記他のネットワーク系内において、前記情報取得ステップと、前記特徴量情報生成ステップと、前記電子署名データ生成ステップと、前記ヘッダ情報格納ステップとが実行されることを特徴とする電子メール情報管理方法。
【図面の簡単な説明】
【０１２６】
【図１】本発明の実施の形態全体の原理説明ブロック図である。
【図２】本発明の実施の形態の原理説明を示す処理フローチャートである。
【図３】本発明の第１の実施の形態（登場エンティティ、環境）を示す図である。
【図４】第１の実施形態におけるＳＭＴＰサーバ１による署名付加処理を示す図である。
【図５】第１の実施形態におけるドメイン２内のPOPサーバ１による署名検証処理を示す図である。
【図６】第１の実施形態におけるドメイン２内のMLサーバによるヘッダ変更処理を示す図である。
【図７】第１の実施形態におけるＳＭＴＰサーバ２による署名付加処理を示す図である。
【図８】第１の実施形態におけるPOPサーバ２による署名ヘッダ情報改ざん検証処理を示す図である。
【図９】第１の実施形態におけるPOPサーバ２による項目特徴量情報検証処理を示す図である。
【図１０】第１の実施形態におけるPOPサーバ２による署名ヘッダ情報検証処理を示す図である。
【図１１】MIME-multipart電子メール情報の一例を示す図である。
【図１２】第２の実施形態におけるＳＭＴＰサーバ１による署名付加後のMIME-multipart電子メール情報を示す図である。
【図１３】第２の実施形態におけるＳＭＴＰサーバ２による署名付加後のMIME-multipart電子メール情報を示す図である。
【図１４】第２の実施形態におけるＳＭＴＰサーバ２による署名付加後のMIME-multipart電子メール情報（X-Content-Type付加時）を示す図である。
【符号の説明】
【０１２７】
１  電子情報、２  署名ヘッダ情報、１０  ヘッダ情報特徴量生成部、２０  本文情報特徴量生成部、３０  署名ヘッダ情報生成部、３０−１  特徴量集合生成部、３０−２  署名付加順序情報取得部、３０−３  署名情報生成部、４０  署名ヘッダ情報格納部、５０  電子情報検証部、５０−１  署名ヘッダ情報改ざん検証部、５０−２  項目特徴量情報検証部、５０−３  署名ヘッダ情報検証部。
【図１】
0004444998.tif 000002
【図２】
0004444998.tif 000003
【図３】
0004444998.tif 000004
【図４】
0004444998.tif 000005
【図５】
0004444998.tif 000006
【図６】
0004444998.tif 000007
【図７】
0004444998.tif 000008
【図８】
0004444998.tif 000009
【図９】
0004444998.tif 000010
【図１０】
0004444998.tif 000011
【図１１】
0004444998.tif 000012
【図１２】
0004444998.tif 000013
【図１３】
0004444998.tif 000014
【図１４】
0004444998.tif 000015