JP4262181B2 - メール配送システム、メール配送方法、メール配送プログラムおよびメール中継装置 - Google Patents

Description

この発明は、発信者端末から発信されたメールを中継して着信者端末に配送するメール配送システム、メール配送方法、メール配送プログラムおよびメール中継装置に関する。

近年、企業が管理する顧客名簿の漏洩に起因して、顧客名簿に記載された顧客の電子メールアドレス宛に詐欺目的の「なりすましメール」が送信される事件が多く発生している。より具体的には、顧客名簿を不正に入手した詐欺業者が、実在の企業を装って顧客のメールアドレス宛に「弊社の懸賞に当選いたしましたので、下記のアドレスのＷｅｂページに訪問して、住所・電話番号・クレジットカード番号・暗証番号を入力して下さい」といった文章が入ったメールを送信して偽のＷｅｂページに顧客を呼び込み、クレジットカード番号や暗証番号を不正に収集するフィッシング詐欺と呼ばれる事件が発生している。

つまり、電子メールの転送プロトコルでは、発信者を認証する必要性を考慮していないので、発信する電子メールの発信者アドレス（Fromアドレス）欄に他人のアドレスを偽って設定することもできる。このため、フィッシング詐欺を行う詐欺業者も、顧客に送信するメールの発信者アドレスに、顧客が信用する企業の名前（メールアドレス）を偽って設定することで、真の企業であるかのようになりすますことも容易である。このような状況下、顧客にとっては、真の企業からメールを受信するだけでなく詐欺業者からもメールを受信する可能性が大いにあり、受信したメールが正当な企業から発信されたものであるか否かを顧客において如何にして判別できるようにするかが重要な課題になっている。

かかる課題に適用される従来技術（メッセージ発信者の正当性を確認するための従来技術）として、例えば、以下の非特許文献１に開示されている電子署名技術がある。これを具体的に説明すると、メッセージであるメールの発信者はペアとなる秘密鍵および公開鍵を生成し、この公開鍵を何らかの方法で着信者に伝える。そして、発信者はメッセージを送信する際に、メッセージの内容を入力とするハッシュ関数によってダイジェストデータを生成した後に、秘密鍵を用いてダイジェストデータに対する署名データを生成し、この署名データをメッセージとともに着信者に送信する。一方、かかるメッセージを受信した着信者は、メッセージの内容から発信者と同じ手順でダイジェストデータを生成するとともに、署名データを公開鍵で復号化してダイジェストデータを復号し、両者のダイジェストデータが同じであれば署名データは正当であると判別する。つまり、受信したメッセージが正当な発信者から発信されたものであるかを署名データに基づいて判別する。

なお、上記した電子署名技術のメールへの応用については、ＩＰＡ（情報処理推進機構）から発行された２０００年度調査・研究報告書「電子メールのセキュリティ Ｓ／ＭＩＭＥを利用した暗号化と電子署名」の第三章でも紹介されている。また、ここで紹介されているＳ／ＭＩＭＥは、ＩＥＴＦ（The Internet Engineering Task Force）によって規定された電子メールの暗号化・署名付加方式であり、１９９８年に公開されたＩＥＴＦ文書「ＲＦＣ−２３１１」にも記載されている。なお、現に市場で入手可能な電子メールソフトの一部には、Ｓ／ＭＩＭＥに対応したものもある。

"電子メールのセキュリティ ３．３ 電子署名"、情報処理復興事業協会 セキュリティセンター、［online］、［２００４年８月３１日検索］、インターネット＜http://www.ipa.go.jp/security/fy12/contents/smime/email_sec03.html_3_3＞

しかしながら、上記した従来の技術は、以下に述べるように、詐欺業者による「なりすましメール」を必ずしも判別することができないという問題がある。すなわち、上記した従来の技術では、メールが発信される発信者の端末（例えば、企業における業務担当者の端末）において、署名データの作成に用いる署名鍵（例えば、企業のＦＲＯＭアドレスに対応付けられた秘密鍵）が管理されるので、例えば、業務担当者の不正行為などによる署名鍵の漏洩を完全に防止することは無理であり、漏洩した署名鍵が詐欺業者に渡って署名データが生成されると、正当なメールであるかのように簡単になりすまされてしまう。

その一方で、かかる署名鍵の漏洩に対しては、署名鍵を頻繁に更新することや、漏洩した署名鍵を無効にする等の対策を講じることも考えられるが、署名鍵を更新するためには公開鍵証明機関から鍵証明書を再取得する必要がある等の理由から、署名鍵を頻繁に更新すること等は必ずしも容易でなく、上記した従来の技術には自ずと限界がある。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、発信者側から秘密情報（署名鍵など）が漏洩する可能性をなくし、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することが可能なメール配送システム、メール配送方法、メール配送プログラムおよびメール中継装置を提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に係る発明は、発信者端末から発信されたメールを中継して着信者端末に配送するメール配送システムであって、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段と、前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手段と、前記発信許可判定手段によって正当なメールであると判定された場合に、当該メールが正当なメールである旨を証明するための証明データとして、前記データ記憶手段に記憶されたデータを取得する証明データ取得手段と、前記証明データ取得手段によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手段と、を備えたことを特徴とする。

また、請求項２に係る発明は、上記の発明において、前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、前記証明データ取得手段は、前記メールの着信者ごとに対応するデータを取得することを特徴とする。

また、請求項３に係る発明は、上記の発明において、前記メールの発信が許可される発信者端末または発側メールサーバのＩＰアドレスを記憶するＩＰアドレス記憶手段をさらに備え、前記発信許可判定手段は、前記メールから発信者端末または発側メールサーバのＩＰアドレスを取得し、当該ＩＰアドレスが前記ＩＰアドレス記憶手段に記憶されていることを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする。

また、請求項４に係る発明は、上記の発明において、前記メールの発信が許可されるために必要な有効条件を含んだ許可情報を生成する許可情報生成手段をさらに備え、前記発信許可判定手段は、前記許可情報生成手段によって生成された許可情報を前記メールとともに前記発信者端末から受け付け、前記メールが前記許可情報に含まれる有効条件を満たすことを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする。

また、請求項５に係る発明は、上記の発明において、正当な発信者として認証された発信者の発信者端末のＩＰアドレスおよび／または発信者アドレスを当該認証後の所定時間に限って有効なアドレスとして記憶するアドレス記憶手段をさらに備え、前記発信許可判定手段は、前記メールから発信者端末のＩＰアドレスおよび／または発信者アドレスを取得し、当該ＩＰアドレスおよび／または発信者アドレスが前記アドレス記憶手段に有効なアドレスとして記憶されていることを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする。

また、請求項６に係る発明は、上記の発明において、前記発信者端末から発信されるメールは、前記メールの着信者の実アドレスに代えて当該実アドレスを識別するための仮ＩＤを含んだメールであって、前記メールの着信者の実アドレスおよび当該実アドレスを識別するための仮ＩＤを対応付けて記憶する実アドレス記憶手段をさらに備え、前記転送処理手段は、前記実アドレス記憶手段に記憶された実アドレスのなかから前記メールに含まれる仮ＩＤに対応する実アドレスを取得し、当該実アドレスを宛先として前記メールを転送することを特徴とする。

また、請求項７に係る発明は、上記の発明において、前記転送処理手段は、前記メールの発信者の実アドレスに代わる別アドレスを生成し、前記メールの発信元を当該別アドレスに置換して転送することを特徴とする。

また、請求項８に係る発明は、上記の発明において、前記転送処理手段は、前記発信者の別アドレスとして、前記メールの着信者ごとに異なる別アドレスを生成することを特徴とする。

また、請求項９に係る発明は、発信者端末から発信されたメールを中継して着信者端末に配送するメール中継装置であって、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段と、前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手段と、前記発信許可判定手段によって正当なメールであると判定された場合に、当該メールが正当なメールである旨を証明するための証明データとして、前記データ記憶手段に記憶されたデータを取得する証明データ取得手段と、前記証明データ取得手段によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手段と、を備えたことを特徴とする。

また、請求項１０に係る発明は、発信者端末から発信されたメールを中継して着信者端末に配送するメール配送方法であって、前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定工程と、前記発信許可判定工程によって正当なメールであると判定された場合に、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段から、当該メールが正当なメールである旨を証明するための証明データとして、データを取得する証明データ取得工程と、前記証明データ取得工程によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理工程と、を含んだことを特徴とする。

また、請求項１１に係る発明は、上記の発明において、前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、前記証明データ取得工程は、前記メールの着信者ごとに対応するデータを取得することを特徴とする。

また、請求項１２に係る発明は、発信者端末から発信されたメールを中継して着信者端末に配送するメール配送方法をコンピュータに実行させるメール配送プログラムであって、前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手順と、前記発信許可判定手順によって正当なメールであると判定された場合に、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段から、当該メールが正当なメールである旨を証明するための証明データとして、データを取得する証明データ取得手順と、前記証明データ取得手順によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手順と、をコンピュータに実行させることを特徴とする。

また、請求項１３に係る発明は、上記の発明において、前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、前記証明データ取得手順は、前記メールの着信者ごとに対応するデータを取得することを特徴とする。

請求項１、９、１０または１２の発明によれば、着信者が受け取る証明データ（正当なメールである旨を証明するための証明データ）となるデータを発信者には知られない状態で管理するので、例えば、業務担当者の不正行為などによって証明データとなるデータが漏洩するなど、発信者側からデータが漏洩する可能性はなくなり、かかるデータの漏洩に起因した「なりすましメール」の発生を防止することが可能になる。その結果、着信者が受け取る証明データが正規のものであれば、発信者以外の信頼ある第三者によって証明データが生成されたことが常に保証されるので、着信者は証明データを信頼した上でメールの正当性を判別することが可能になる。また、業務担当者などの発信者側からデータが漏洩する可能性はなくなるので、署名鍵（秘密情報）を頻繁に更新することや、漏洩した署名鍵を無効にする等の対策を講じる必要もなくなり、このような煩雑な対策を講じることなく「なりすましメール」の発生を防止することが可能になる。さらに、着信者のみが知っているデータを証明データとして用いるので、鍵を用いた証明データの生成に比較して、簡易に証明データを生成することが可能になる。また、着信者においては証明データを検証する処理が不要になるので、検証を実現するための機能（例えば、検証サーバにアクセスするためのブラウザ、署名データの検証も行うメーラなど）を着信者端末に用意する必要もなくなり、メールを着信できるメーラを用意するだけで、着信者は簡易にメールの正当性を判別することが可能になる。
また、請求項２の発明によれば、着信者ごとに異なるデータを用いるので、証明データの偽造が困難になり、証明データの信頼性を高めることが可能になる。

また、請求項３の発明によれば、予めメール発信が許可されている発信者端末または発側メールサーバからメールが発信されることを必要条件として正当なメールである旨を判定するので、例えば、企業内の業務担当者のみが操作できる発信者端末や、企業内の発側メールサーバの傘下にある発信者端末からのみメール発信を許可することで、業務担当者以外の者が操作できる発信者端末や企業外の発信者端末など、不正行為が行われるおそれがある発信者端末から発信されたメールを不正なメールとして排除することが可能になる。

また、請求項４の発明によれば、メールとともに受け付けた許可情報に含まれる有効条件（例えば、メールの発信が許可される期限、発信者アドレスなど）を満たすことを必要条件として正当なメールである旨を判定するので、メールの発信が許可されるために必要な有効条件を詳細に設定することで、正当なメールと判定できる範囲を実用的な範囲に制限することが可能になる。

また、請求項５の発明によれば、メール発信に先立って発信者を認証した上で、正当な発信者として認証された発信者の発信者端末のＩＰアドレスや発信者アドレスを当該認証後の所定時間に限って有効なアドレスとして記憶しておき、メールから取得した発信者端末のＩＰアドレスや発信者アドレスが有効なアドレスとして記憶されていることを必要条件にして正当なメールである旨を判定するので、いわゆるパスワード認証や生体認証等の各種の認証手法を適宜採用して、不正な発信者を事前に排除することが可能になる。また、メールとともに許可情報（発信者認証が成功した旨を示す情報）を送信する手間を発信者に強いることなしに、不正な発信者を簡易に排除することが可能になる。

また、請求項６の発明によれば、実アドレスに代えて仮ＩＤを宛先アドレスとするメールを発信者端末から受け付け、仮ＩＤに対応する実アドレスに宛先アドレスを置換してメールを転送するので、例えば、メールの発信者となる業務担当者などに対しては仮ＩＤのみを知らせ、着信者である顧客の実アドレスまでは知らせる必要がなくなり、業務担当者から顧客の実アドレスが漏洩する事態を防止することが可能になる。

また、請求項７の発明によれば、発信者の実アドレスに代わる別アドレスを生成し、発信者アドレスを別アドレスに置換してメールを転送するので、例えば、メールの発信者となる業務担当者などに対して実アドレスのみを知らせ、着信者である顧客の目に触れる別アドレスまでは知らせないようにすることができ、これによって、別アドレスを用いたメールを不正に生成することが困難になり、この観点からも「なりすましメール」の発生を防止することが可能になる。

また、請求項８の発明によれば、着信者ごとに異なる別アドレスを生成するので、別アドレスの偽造が困難になり、「なりすましメール」の発生を一層防止することが可能になる。

以下に添付図面を参照して、この発明に係るメール配送システム、メール配送方法、メール配送プログラムおよびメール中継装置の実施例１〜４を詳細に説明する。

実施例１では、実施例１で用いる用語、実施例１に係るメール配送システムの概要および特徴を説明した後に、メール配送システムの構成、システムにおける各装置の詳細、システムにおける処理の流れなどを説明し、最後に実施例１の効果を説明する。

［用語の説明（実施例１）］
最初に、実施例１で用いる主要な用語を説明する。実施例１で用いる「発信者」とは、メール（メッセージ）を発信する利用者のことであり、例えば、企業における業務担当者がこれに該当する。また、実施例１で用いる「着信者」とは、上記のメールを着信する利用者のことであり、例えば、企業における顧客がこれに該当する。すなわち、本実施例では、企業における業務担当者が顧客に対してメールを送信する場合を想定している。

また、実施例１で用いる「秘密鍵（特許請求の範囲に記載の「秘密情報」に対応する）」とは、後述する証明コードの生成に用いる鍵のことであり、例えば、ＲＳＡ署名のための秘密鍵がこれに該当する。そして、実施例１で用いる「証明データ」とは、発信者から発信されたメールが当該発信を許可された正当なメールである旨（言い換えれば、詐欺業者から発信された「なりすましメール」ではない旨）を証明するためのコードのことであり、例えば、上記の秘密鍵を用いてメールのヘッダ情報から生成される署名データがこれに該当する。

［システムの概要および特徴（実施例１）］
続いて、図１を用いて、実施例１に係るメール配送システムの概要および特徴を説明する。図１は、実施例１に係るメール配送システムの概要を説明するための図である。

実施例１に係るメール配送システムの概要は、発信者端末から発信されたメールを中継して着信者端末に配送するものである。そして、着信者は、上記した証明データとともにメールを着信するが、実施例１では、かかる証明データの生成に用いる秘密情報（秘密鍵）が発信者側から漏洩する可能性をなくし、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することを可能にしている点に主たる特徴がある。

これについて図１を用いて簡単に説明すると、実施例１に係るメール配送システムにおいて、発着信者以外の第三者であるメール中継者は、正当な発信者がメール発信に用いる発信者アドレスと、この発信者から正当に発信されたメールが経由する発側メールサーバのＩＰアドレスとを対応付けて記憶する発信許可情報記憶部を有する。つまり、例を挙げれば、企業の業務担当者が顧客にメールを送信する際に用いるメールアドレスと、企業内に設置されている発側メールサーバのＩＰアドレスとを対応付けて記憶する。さらに、メール中継者は、上記した証明データの生成に用いる秘密鍵および当該証明データの検証に用いる公開鍵を有する。

そして、メール中継者は、発信者から着信者のメールアドレス宛に発信されたメールを受信すると（図１の（１）参照）、かかるメールが発信を許可された正当なメールであるか否かを判定する（図１の（２）参照）。具体的には、発信者から受信したメールのヘッダ情報から発信者アドレス（ＦＲＯＭアドレス）および経路情報（メールが送られてくる段階で経由した発側メールサーバのＩＰアドレス）を取り出し、これらの発信者アドレスおよびＩＰアドレスが発信許可情報記憶部に対応付けて記憶されているかを判定し、両者が対応付けて記憶されている場合には、正当なメールである旨を判定する。

かかる判定で正当なメールである旨が判定された場合には、メール中継者は、発信者から発信されたメールが発信を許可された正当なメールである旨を証明する証明データを生成する（図１の（３）参照）。具体的には、上記した秘密鍵を用いてメールのヘッダ情報から生成される証明データ（ヘッダ情報を秘密鍵で暗号化してなる署名データ）を生成する。これに続いて、メール中継者は、かかる証明データをメールのヘッダや本文に挿入し、当該証明データが挿入されたメールを着信者に転送する（図１の（４）参照）。なお、上記の例で言えば、詐欺業者などが業務担当者のメールアドレスを発信者アドレスとして用いて顧客にメールを発信した場合には、企業外に設置された発側メールサーバを経由することになるので、メール中継者は、正当なメールではないと判定して、このメールを着信者に転送することなく破棄する。

その一方、かかる証明データ付きメールを受信した着信者は、受信したメールのヘッダ情報およびメールに挿入されている証明データをメール中継者に送信して、証明データの検証を要求する（図１の（５）参照）。そして、かかる検証要求を受け付けたメール中継者は、証明データが正規のものであるか否かを検証する（図１の（６）参照）。具体的には、着信者から受け付けた証明データを上記した公開鍵で復号化することでメールのヘッダ情報を復号し、このヘッダ情報が着信者から受け付けたヘッダ情報と一致するか否かを検証し、両者が一致する場合には、証明データが正規のものである旨を判定する。

かかる検証で証明データが正規のものである旨が判定された場合には、メール中継者は、その旨（検証ＯＫ）の検証結果を着信者に通知し、これとは反対に、証明データが正規のものではない旨が判定された場合には、その旨（検証ＮＧ）の検証結果を着信者に通知する（図１の（７）参照）。なお、上記の例で言えば、詐欺業者などが正規の秘密鍵を入手できずに偽の証明データを生成し、この証明データが挿入されたメールを顧客に送信したような場合には、偽の証明データについて検証要求を受け付けたメール中継者では、証明データが正規のものではないと判定し、検証ＮＧの検証結果を着信者に通知する。

このように、実施例１に係るメール配送システムでは、着信者が受け取る証明データ（正当なメールである旨を証明するための証明データ）を作成するための秘密情報（秘密鍵）をメール中継者が発信者には知られない状態で管理するので、例えば、業務担当者の不正行為などによって証明データを生成するための秘密情報が漏洩するなど、発信者側から秘密情報が漏洩する可能性はなくなり、上記した主たる特徴の如く、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することが可能になる。

［システムの構成（実施例１）］
続いて、図２を用いて、実施例１に係るメール配送システムの構成を説明する。図２は、実施例１に係るメール配送システムの構成を示す図である。

同図に示すように、このメール配送システムは、発信者端末１と、着信者端末２と、発側メールサーバ３と、着側メールサーバ４と、メール中継装置１０と、証明データ処理装置２０とを、ネットワーク（インターネット５、ＬＡＮ６、ルータＲ、ファイアウォールなどによって形成される通信網）を介して相互に通信可能に接続して構成される。以下に、各装置の役割や構成を説明する。

［発信者端末および着信者端末（実施例１）］
このうち、発信者端末１は、少なくとも電子メールソフトがインストールされた、既知のパーソナルコンピュータやワークステーション、家庭用ゲーム機、インターネットＴＶ、ＰＤＡ、あるいは携帯電話やＰＨＳの如き移動体通信端末などである。より詳細には、発信者端末１は、発信者（例えば、企業における業務担当者など）が利用する端末であり、主として、発信者のメールアドレスを宛先アドレスとするメール（図６参照）をメール中継装置１０に発側メールサーバ３を経由して送信する役割を有する。

なお、発信者端末１の電子メールソフトには、発信者端末１が利用するメールサーバである発側メールサーバ３の情報、発信者端末１を利用する発信者の識別情報（発信者のメールアドレスもしくは発側メールサーバ３が認識する発信者のユーザＩＤ）が設定情報として登録されている。

また、着信者端末２は、少なくとも電子メールソフトやＷｅｂブラウザがインストールされた、既知のパーソナルコンピュータやワークステーション、家庭用ゲーム機、インターネットＴＶ、ＰＤＡ、あるいは携帯電話やＰＨＳの如き移動体通信端末などである。より詳細には、着信者端末２は、着信者（例えば、企業の顧客など）が利用する端末であり、主として、着信者のメールアドレスを宛先アドレスとし、証明データが挿入されたメール（図９参照）をメール中継装置１０から着側メールサーバ４を介して受信する役割、証明データ処理装置２０にアクセスして証明データの検証要求に係るメッセージ（図１０参照）を送信する役割、証明データの検証結果に係るメッセージ（図１２参照）を証明データ処理装置２０から受信する役割などを有する。

なお、着信者端末２の電子メールソフトには、着信者端末２が利用するメールサーバである着側メールサーバ４の情報、着信者端末２を利用する着信者の識別情報（着信者のメールアドレスもしくは着側メールサーバ４が認識する着信者のユーザＩＤ）が設定情報として登録されている。また、着信者には、顧客としてのサービス加入時に企業から配布される「サービス利用手引き」などを通じて、後述する証明コード処理装置２０のＵＲＬ（Uniform Resource Locator）が連絡されており、例えば、着信者は、このＵＲＬを着信者端末２のＷｅｂブラウザにいわゆる「お気に入り」として登録する。

［発側メールサーバおよび着側メールサーバ（実施例１）］
次に、発側メールサーバ３は、少なくともメール転送機能を備えた既知のメールサーバである。より詳細には、発側メールサーバ３は、発信者が利用するメールサーバ（例えば、企業内に設置されたメールサーバ）であり、主として、発信者端末１からメールを受信して、当該メールの宛先アドレスに基づいて次段のメールサーバを決定し、かかる次段のメールサーバにメールを転送する役割を有する。

具体的には、実施例１の場合には、発側メールサーバ３の電子メールサーバソフト（メール転送ソフト）の設定情報として、受信したメールの全てを後述するメール中継装置１０に転送させるルーチング設定が登録されており、これによって、発側メールサーバ３を経由するメールは全てメール中継装置１０に転送されるようにしている。なお、かかるルーチング設定を発側メールサーバ３に登録するのではなく、例えば、発信者端末１から発信されるメールの宛先アドレスにおける＠以降のドメイン名にメール中継装置１０を示す情報を含ませることで、かかる宛先アドレスのメールを発側メールサーバ３からメール中継装置１０に転送するようにしてもよい。

また、例えば、企業内に発側メールサーバ３を設置するような場合には、いわゆるファイアウォールの設置や、発側メールサーバ３の電子メールサーバソフトに対する制限的設定などによって、発側メールサーバ３に対してメールを発信することが可能な発信者端末１を企業内の発信者端末１に限定するようにしてもよい。

一方、着側メールサーバ４は、少なくともメール転送機能やメールボックス提供機能を備えた既知のメールサーバである。より詳細には、着側メールサーバ４は、着信者が利用するメールサーバ（例えば、企業の顧客がそれぞれ利用しているＩＳＰのメールサーバ）であり、主として、メール中継装置１０などからメールを受信して、当該メールの宛先アドレスに基づいて次段のメールサーバまたはメールボックス（着信者のメールアドレスごとに割り当てられたメール記憶手段）を決定し、かかる次段のメールサーバまたはメールボックスにメールを転送する役割や、着信者端末２からメール確認要求を受信して、当該メール確認要求を行った着信者のメールアドレスに対応するメールボックスに到着しているメールを取り出し、メール確認応答として着信者端末２に送信する役割を有する。

［メール中継装置（実施例１）］
次に、メール中継装置１０は、発信者端末１から発信されたメールを中継して着信者端末２に配送するサーバ装置であり、主として、メールの発信者が知らない所定の秘密情報（秘密鍵）を記憶する役割、着信者のメールアドレスを宛先アドレスとし、発信者端末１から発信されて着側メールサーバ３を経由したメール（図７参照）を受信する役割、受信したメールが発信を許可された正当なメールであるか否かを判定する役割、正当なメールである旨を証明するための証明データを秘密鍵で生成する役割、証明データが挿入されたメール（図９参照）を着信者端末２に転送する役割などを有する。

そして、このメール中継装置１０は、本発明に密接に関連するものとして、図２に示すように、メール送受信部１１と、発信許可情報記憶部１２と、正当性判定部１３と、秘密情報記憶部１４と、証明データ生成部１５と、転送処理部１６とを備える。なお、発信許可情報記憶部１２は特許請求の範囲に記載の「ＩＰアドレス記憶手段」に対応し、正当性判定部１３は同じく「発信許可判定手段」に対応し、秘密情報記憶部１４は同じく「秘密情報記憶手段」に対応し、証明データ生成部１５は同じく「証明データ生成手段」に対応し、転送処理部１６は同じく「転送処理手段」に対応する。

このうち、メール送受信部１１は、いわゆるＳＭＴＰ（Simple Mail Transfer Protocol）等の通信プロトコルに従って、発信者端末１（より詳細には発側メールサーバ３）や着信者端末２（より詳細には着側メールサーバ４）等との間における通信を制御する処理部である。具体的には、発信者端末１から発信されて発側メールサーバ３を経由したメール（図７参照）を受信する処理、証明データが挿入されたメール（図９参照）を着側メールサーバ４を経由させて着信者端末２に送信する処理などを実行する。

発信許可情報記憶部１２は、発信を許可された正当なメールを特定するための発信許可情報を記憶する手段である。具体的に説明すると、図５は、発信許可情報記憶部１２に記憶される情報の例を示す図であるが、同図に例示するように、正当な発信者がメール発信に用いる発信者アドレスと、この発信者から正当に発信されたメールが経由する発側メールサーバ３のＩＰアドレスとを対応付けて記憶して構成される。つまり、例を挙げれば、企業の業務担当者が顧客にメールを送信する際に用いるメールアドレスと、企業内に設置されている発側メールサーバ３のＩＰアドレスとを対応付けて記憶する。

正当性判定部１３は、発信者端末１から発信されたメールが発信を許可された正当なメールであるか否かを判定する処理部である。具体的に説明すると、図７は、メール中継装置１０が受信するメールの例を示す図であるが、同図に示すように、発信者端末１から発信されて着側メールサーバ３を経由して受信したメールには、ＴＯアドレスやＦＲＯＭアドレスなどからなるヘッダ情報が含まれる。かかるメールのヘッダ情報から、正当性判定部１３は、発信者アドレス（ＦＲＯＭアドレス）および経路情報（メールが送られてくる段階で経由した発側メールサーバ３のＩＰアドレス）を取り出し、これらの発信者アドレスおよびＩＰアドレスが発信許可情報記憶部１２に対応付けて記憶されているかを判定し、両者が対応付けて記憶されている場合には、正当なメールである旨を判定する。

秘密情報記憶部１４は、メールの発信者が知らない所定の秘密情報であって、証明データの生成に用いる秘密鍵（例えば、ＲＳＡ署名のための秘密鍵）を記憶する手段である。なお、この秘密鍵は、後述する証明データ処理装置２０の検証用情報記憶部２２に記憶される公開鍵と対（ペア）になっている。

証明データ生成部１５は、正当性判定部１３によって正当なメールである旨が判定された場合に、当該メールが発信を許可された正当なメールである旨を証明する証明データを生成する処理部である。具体的に説明すると、図８は、証明データの生成を説明するための図であるが、同図に示すように、メールのヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）を、秘密情報記憶部１４に記憶された秘密鍵で暗号化することによって証明データ（ヘッダ情報を秘密鍵で暗号化してなる署名データ）を生成する。なお、ＲＳＡ署名のための秘密鍵を用いる場合には、ＲＳＡ署名アルゴリズムによってヘッダ情報に対して署名することで証明データを生成する。

転送処理部１６は、証明データ生成部１５によって生成された証明データを正当なメールに挿入し、当該証明データが挿入されたメールをメール送受信部１１から着信者端末２（より詳細には着側メールサーバ４）に転送する処理部である。具体的に説明すると、図９は、メール中継装置１０が転送するメールの例を示す図であるが、転送処理部１６は、証明データ（例えば「abrsRwrXgs8」）をメールのヘッダ部分（例えば「X-Sender-Signature」という項目）および本文末尾（例えば「発信者署名」という項目）に挿入し、このメールを転送する。なお、署名データの挿入箇所は、１箇所もしくは複数箇所のいずれであってもよい。

なお、上述してきたメール中継装置１０や後述する証明データ処理装置２０は、例えば、発信者端末１や発側メールサーバ３と同様の企業内に設定されて、一部のセキュリティ責任者のみが操作を許可されるように管理される。言い換えれば、一般の業務担当者が操作することができないように管理される。ただし、この実施形態は一例に過ぎず、データセンタ業者などの信頼ある別の業者が、メール中継装置１０や証明データ処理装置２０を管理する実施形態であってもよい。

［証明データ処理装置（実施例１）］
次に、証明データ処理装置２０は、上記した証明データを検証するサーバ装置であり、主として、着信者端末２から証明データの検証要求を受け付ける役割、着信者端末２から受け付けた証明データが正規のものであるかを検証する役割、証明データの検証結果を着信者端末２に送信する役割などを有する。そして、この証明データ処理装置２０は、本発明に密接に関連するものとして、図２に示すように、ＨＴＴＰ通信部２１と、検証用情報記憶部２２と、証明データ検証部２３とを備える。

このうち、ＨＴＴＰ通信部２１は、いわゆるＨＴＴＰ（Hyper Text Transfer Protocol）等の通信プロトコルに従って、着信者端末２等との間における通信を制御する処理部である。具体的には、着信者端末２からアクセス要求メッセージを受信する処理、ヘッダ情報および証明データを入力させる検証フォームからなるアクセス応答メッセージを着信者端末２に送信する処理、着信者端末２から証明データの検証要求メッセージ（図１０参照）を受信する役割、証明データの検証結果メッセージ（図１２参照）を着信者端末２に送信する処理などを実行する。

検証用情報記憶部２２は、証明データの検証に用いる検証鍵（例えば、ＲＳＡ署名の秘密鍵で暗号化されたデータを復号するための公開鍵）を記憶する手段である。なお、この公開鍵は、上記したメール中継装置１０の秘密情報記憶部１４に記憶される秘密鍵と対（ペア）になっている。

証明データ検証部２３は、着信者端末２から受け取った証明データが正規のものであるかを検証する処理部である。具体的に説明すると、図１０は、着信者端末２に表示される検証要求ページの例を示す図であるが、Ｗｅｂブラウザを用いて証明データ処理装置２０にアクセスした着信者端末２のモニタ等には、同図に示すような「検証要求ページ」が出力され、かかるページに対して検証希望のメールに含まれるヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）および証明データがキーボードやマウスを介して着信者から入力されると、着信者端末２は、これらの入力情報からなる検証要求メッセージを証明データ処理装置２０に送信する。

そして、図１１は、証明データの検証を説明するための図であるが、同図に示すように、証明データ検証部２３は、検証要求メッセージに含まれる証明データ（署名データ）を、検証用情報記憶部２２に記憶された公開鍵で復号化することによってメールのヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）を復号し、このヘッダ情報が検証要求メッセージに含まれるヘッダ情報と一致するか否かを検証し、両者が一致する場合には、証明データが正規のものである旨を判定する。なお、ここでは、証明データを公開鍵で復号する例を示したが、証明データの検証に際して必ずしも公開鍵による復号が行われるわけではなく、例えば、ＲＳＡ署名のための秘密鍵を用いて証明データを生成したような場合には、公開鍵を用いたＲＳＡ署名の検証アルゴリズムによって証明コードを検証することになる。

［メールの発信から受信に至る処理（実施例１）］
続いて、図３などを用いて、上記したメール配送システムにおけるメールの発信から受信に至る処理の流れを説明する。図３は、メールの発信から受信に至る処理の流れを示すシーケンス図である。

同図に示すように、メール中継装置１０は、発信者端末１から着信者のメールアドレス宛に発信されたメールを発側メールサーバ３経由で受信する（ステップＳ３０１）。具体的には、図６は、発信者端末１から発信されるメールの例を示す図であるが、発信者端末１では、発信者アドレス（例えば、企業の業務担当者が顧客にメールを送信する際に用いるメールアドレス）がＦＲＯＭ欄に記載され、顧客のアドレスがＴＯ欄に記載されたメールがキーボードやマウスを介して発信者によって作成されると、このメールを発側メールサーバ３に送信する。そして、発側メールサーバ３は、発信者端末１から受信したメールをメール中継装置１０に送信するが、その結果として、メール中継装置１０が受信するメールのヘッダ情報には、図７に例示したように、経路情報（メールが送られてくる段階で経由した発側メールサーバ３のＩＰアドレス）が追加される。

かかるメールを受信したメール中継装置１０では、当該メールが発信を許可された正当なメールであるか否かを判定する（ステップＳ３０２）。具体的には、メールのヘッダ情報から発信者アドレスおよび発側メールサーバ３のＩＰアドレスを取り出し、これらが発信許可情報記憶部１２に対応付けて記憶されているかを判定し、両者が対応付けて記憶されている場合には、正当なメールである旨を判定する。

このようにしてメールの正当性が判定されると、メール中継装置１０は、当該メールが発信を許可された正当なメールである旨を証明する証明データを生成する（ステップＳ３０３）。具体的には、図８に例示したように、メールのヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）を、秘密情報記憶部１４に記憶された秘密鍵で暗号化することによって証明データを生成する。

その後、メール中継装置１０は、上記のステップＳ３０３で生成された証明データを正当なメールに挿入し、当該証明データが挿入されたメールを着側メールサーバ４に転送する（ステップＳ３０４）。具体的には、証明データ（例えば「abrsRwrXgs8」）をメールのヘッダ部分および本文末尾に挿入し、このメール（図９参照）を着側メールサーバ４に転送する。なお、上記のステップＳ３０２で正当なメールではないと判定されたメールについては、着信者（着側メールサーバ４）に転送されることなく破棄される。

一方、着側メールサーバ４は、メール中継装置１０から受信した証明データ付きメールをメールボックスに保存する（ステップＳ３０５）。具体的には、メール中継装置１０から受信したメールにおける宛先アドレスのユーザ名部分（メールアドレスの＠以前の文字列）に基づいて着信者（ユーザＩＤ）を識別し、かかるユーザＩＤによって識別される着信者のメールボックスに証明データ付きメールを保存する。

そして、着信者端末２では、任意のタイミングで（着信者の指示に応じて、もしくは、所定時間ごと定期的に）着側メールサーバ４に対してメール確認要求メッセージを送信する（ステップＳ３０６）。具体的には、着信者端末２の電子メールソフトにおける到着メール確認メニューがキーボードやマウスを介して着信者によって選択されると、着信者端末２は、上記した設定情報に基づいて、着信者端末２を利用する着信者の識別情報（着信者のメールアドレスもしくは着側メールサーバ４が認識する着信者のユーザＩＤ）を伴ったメール確認要求メッセージを着側メールサーバ４に対して送信する。

かかるメール確認要求メッセージを受信した着側メールサーバ４では、メール確認応答として、メールボックスに到着しているメールを着信者端末２に送信する（ステップＳ３０７）。具体的には、メール確認要求メッセージから着信者の識別情報（ユーザＩＤ）を取り出し、かかるユーザＩＤに対応するメールボックスに到着しているメールを着信者端末２に送信する。その結果、証明データが挿入されたメール（図９参照）が着信者端末２のモニタ等に出力されることになる。

［証明データの検証に至る処理（実施例１）］
続いて、図４などを用いて、上記したメール配送システムにおける証明データの検証に至る処理の流れを説明する。図４は、証明データの検証に至る処理の流れを示すシーケンス図である。

同図に示すように、着信者端末２が受信したメールが「なりすましメール」ではない正当なメールであるかを確かめたい着信者は、着信者端末２を介して証明データ処理装置２０にアクセス要求メッセージを送信する（ステップＳ４０１）。具体的には、着信者端末２のＷｅｂブラウザにおいて証明データ処理装置２０のＵＲＬがアクセス先アドレスとして入力されると、着信者端末２は、証明データ処理装置２０にアクセス要求メッセージをＨＴＴＰ要求の形式で送信する。

かかるアクセス要求メッセージを受信した証明データ処理装置２０では、ヘッダ情報および証明データを入力させる検証フォームからなるアクセス応答メッセージを着信者端末２に送信する（ステップＳ４０２）。具体的には、図１０に例示するように、ヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）の入力フィールド、証明データの入力フィールド、送信ボタンおよびキャンセルボタンからなるＨＴＭＬページを着信者端末２に送信する。

これに対して、着信者端末２では、検証希望のメールに含まれるヘッダ情報および証明データからなる検証要求メッセージを証明データ処理装置２０に送信する（ステップＳ４０３）。具体的には、アクセス応答メッセージを受信した着信者端末２のモニタ等には、図１０に例示したような「検証要求ページ」が出力されるが、かかるページに対して検証希望のメールに含まれるヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）および証明データがキーボードやマウスを介して着信者から入力され、かつ、送信ボタンが押下されると、着信者端末２は、これらの入力情報からなる検証要求メッセージを証明データ処理装置２０に送信する。

そして、着信者端末２から検証要求メッセージを受信した証明データ処理装置２０は、受信した検証要求メッセージに含まれる証明データが正規のものであるかを検証する（ステップＳ４０４）。具体的には、図１１に例示したように、検証要求メッセージに含まれる証明データを、検証用情報記憶部２２に記憶された公開鍵で復号化することによってメールのヘッダ情報（ＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥ、ＳＵＢＪＥＣＴ）を復号し、このヘッダ情報が検証要求メッセージに含まれるヘッダ情報と一致するか否かを検証し、両者が一致する場合には、証明データが正規のものである旨を判定する。

その後、証明データ処理装置２０は、証明データの検証結果メッセージを着信者端末２に送信する（ステップＳ４０５）。具体的には、上記のステップＳ４０４で証明データが正規のものである旨が判定された場合には、その旨（検証ＯＫ）の検証結果を含んだ検証結果通知ページ（図１２参照）を着信者端末２に送信し、これとは反対に、証明データが正規のものではない旨が判定された場合には、その旨（検証ＮＧ）の検証結果を含んだ検証結果通知ページを着信者端末２に送信する。このような検証結果を入手した着信者は、着信者端末２が受信したメールが「なりすましメール」ではない正当なメールであるかを確かめることができる。

［実施例１の効果等］
上述してきたように、実施例１によれば、着信者が受け取る証明データ（正当なメールである旨を証明するための証明データ）を生成するための秘密情報を発信者には知られない状態で管理するので、例えば、業務担当者の不正行為などによって証明データを生成するための秘密情報が漏洩するなど、発信者側から秘密情報が漏洩する可能性はなくなり、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することが可能になる。

そして、その結果として、着信者が受け取る証明データが正規のものであれば、発信者以外の信頼ある第三者によって証明データが生成されたことが常に保証されるので、着信者は証明データを信頼した上でメールの正当性を判別することが可能になる。また、業務担当者などの発信者側から秘密情報が漏洩する可能性はなくなるので、署名鍵（秘密情報）を頻繁に更新することや、漏洩した署名鍵を無効にする等の対策を講じる必要もなくなり、このような煩雑な対策を講じることなく「なりすましメール」の発生を防止することが可能になる。

また、実施例１によれば、予めメール発信が許可されている発側メールサーバ３からメールが発信されることを必要条件として正当なメールである旨を判定するので、例えば、企業内の発側メールサーバ３の傘下にある発信者端末１からのみメール発信を許可することで、企業外の発信者端末１など、不正行為が行われるおそれがある発信者端末１から発信されたメールを不正なメールとして排除することが可能になる。

また、実施例１によれば、鍵を用いてメールから証明データ（署名データ）を生成するので、証明データの偽造が困難になり、証明データの信頼性を高めることが可能になる。

さて、これまで実施例１に係るメール配送システムについて説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、図１３を用いて、以下では実施例２に係るメール配送システムとして、種々の異なる実施例を（１）〜（６）に区分けして説明する。なお、図１３は、実施例２に係るメール配送システムを説明するための図である。

（１）メールの正当性判定
上記の実施例１では、発信が許可される発信者アドレスおよび発側メールサーバ３のＩＰアドレスを対応付けて規定することでメールの正当性を判定する場合を説明したが、本発明はこれに限定されるものではなく、例えば、図１３に示すように、発信者アドレスのドメイン名（発信が許可されるドメイン名）を規定してもよく、また、発信が許可される発信者端末１のＩＰアドレスを規定するようにしてもよい。さらには、発信者アドレスに依存することなく、発側メールサーバ３や発信者端末１のＩＰアドレスのみを規定し、メールのヘッダ情報に含まれる経路情報（発側メールサーバ３や発信者端末１のＩＰアドレス）のみに基づいてメールの正当性を判定するようにしてもよい。

また、このような正当性判定に用いるＩＰアドレスについては、必ずしもメール中継装置１０が管理する必要はなく（ＩＰアドレスを記憶する発信許可情報記憶部を必ずしもメール中継装置１０が備える必要はなく）、例えば、同一ＬＡＮ６内の他の装置、もしくは、ＬＡＮ６外に設けられた他の装置が発信許可情報記憶部を備え、メール中継装置１０が当該他の装置に対してメールの正当性を問い合わせるようにしてもよい。

（２）証明データの生成方式
上記の実施例１では、いわゆる公開鍵暗号化方式によって証明データを生成する場合を説明したが、本発明はこれに限定されるものではなく、例えば、図１３に示すように、共通鍵暗号化方式やメッセージダイジェスト関数を用いて証明データを生成するようにしてもよい。具体的には、共通鍵暗号化方式を採用する場合には、証明データの生成（暗号化）および検証（証明データの復号化）に際して同一鍵を使用する。また、メッセージダイジェスト関数を採用する場合にも、証明データの生成（暗号化によるハッシュ値の生成）および検証（同じく暗号化によるハッシュ値の生成）に際して同一鍵を使用する。なお、公開鍵暗号化方式としては、ＲＳＡ、Diffie-Hellmanなどが用いられ、共通鍵暗号化方式としては、ＲＣ２、ＲＣ５、ＤＥＳ、Triple-DES、ＩＤＥＡなどが用いられ、メッセージダイジェスト関数としては、ＭＤ２（ハッシュ値は１６バイト）、ＭＤ５（１６バイト）、ＳＨＡ１（２０バイト）などが用いられる。

（３）証明データの生成鍵
上記の実施例１では、着信者で区別することなく共通の鍵を用いて証明データを生成する場合を説明したが、本発明はこれに限定されるものではなく、図１３に示すように、着信者ごとの鍵を用いて証明データを生成するようにしてもよい。すなわち、公開鍵暗号化方式を採用する場合には、着信者ごとの秘密鍵および公開鍵を用いて証明データの生成および検証を行うことになる。このように、着信者ごとに異なる鍵を用いて証明データ（署名データ）を生成するようにすれば、証明データの偽造が一層困難になり、証明データの信頼性を一層高めることが可能になる。

（４）署名対象
上記の実施例１では、証明データを生成するために、メールのヘッダ情報に含まれるＦＲＯＭアドレス、ＴＯアドレス、送信ＤＡＴＥおよびＳＵＢＪＥＣＴを暗号化する場合を説明したが、本発明はこれに限定されるものではなく、例えば、図１３に示すように、ヘッダ情報の一部もしくは全てを暗号化するようにしてもよく、さらには、メールの本文（一部または全て）を暗号化することで証明データを生成するようにしてもよい。すなわち、メールに含まれる情報の一部または全てを用いて証明データを生成することができる。

（５）証明データの検証場所
上記の実施例１では、発着信者以外の第三者の装置である証明データ処理装置２０において証明データを検証する場合を説明したが、本発明はこれに限定されるものではなく、図１３に示すように、メールを受け取った着信者端末２において証明データを検証するようにしてもよい。すなわち、この場合には、証明データを検証するための検証用情報（公開鍵）を着信者端末２がそれぞれ有し、かかる公開鍵を用いて証明データを検証することになる。このように、着信者端末２で証明データを検証するようにすれば、着信者端末２から証明データ処理装置２０にアクセスしなければならないという手間を省くことができる。その一方、証明データ処理装置２０で証明データを検証する場合には、汎用の電子メールソフト以外に証明データを検証するための検証用情報（公開鍵）や検証ソフトを着信者端末２が有しなければならないという煩雑さを省くことができる。

（６）システム構成等
上記の実施例１で図示した各装置（例えば、図２に例示したメール中継装置１０、証明データ処理装置２０など）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、メール中継装置１０および証明データ処理装置２０を一体として構成する、証明データ処理装置２０および着信者端末２を一体として構成するなど、各装置の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、上記の実施例１で説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（例えば、メールや画面表示の内容等）については、特記する場合を除いて任意に変更することができる。

なお、上記の実施例１では、本発明を実現する各装置（例えば、メール中継装置１０、証明データ処理装置２０など）を機能面から説明したが、各装置の各機能はパーソナルコンピュータやワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。すなわち、本実施例１で説明した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータ上で実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。つまり、例を挙げれば、実施例１に示したようなメール中継装置用プログラムや、証明データ処理装置用プログラムを格納したＣＤ−ＲＯＭ（装置ごとに別個のＣＤ−ＲＯＭであってもよい）を配布し、このＣＤ−ＲＯＭに格納されたプログラムを各コンピュータが読み出して実行するようにしてもよい。

以下の実施例３では、上記の実施例１と比較した場合の主たる相違点を説明した後に、実施例３に係るメール配送システムの概要および特徴、かかるメール配送システムの構成、システムにおける各装置の詳細、システムにおける処理の流れなどを説明し、最後に実施例３の効果を説明する。

［主たる相違点（実施例３）］
上記の実施例１では、発信者端末１で着信者の実アドレスをメールの宛先アドレスとして入力する必要がある。つまり、業務担当者などに顧客の実アドレスを知らせておくことが前提として必要である。この結果、業務担当者などが顧客の実アドレスを不正に漏洩させることが危惧される。すなわち、上記の実施例３では、正当なメールであるか否かを証明データによって判別できるようにしているものの、顧客の実アドレスが漏洩して不正なメールが送信される危険性を防止することまではできていない。

そこで、実施例３では、発信者には着信者の実アドレスに代えて仮ＩＤを知らせておき、かかる仮ＩＤをメールの宛先アドレスとして入力させ、メール中継者が仮ＩＤから実アドレスを取得して当該実アドレス宛にメールを転送する場合を説明する。ここで、実施例３で用いる「仮ＩＤ」とは、上記の実アドレスに対応付けられて実アドレス（一または複数の実アドレス）を一意に識別する識別情報のことであり、実アドレスに代えて公開され、例えば、企業における業務担当者もアクセスできる顧客情報の一つとして管理される。

また、上記の実施例１では、いわゆる電子署名としての証明データを生成するので、着信者は証明データ処理装置２０にアクセスするか、もしくは、着信者端末２に用意された検証用ソフトを用いるなどして、証明データが正規のものであるかを検証する必要がある。この結果、前者の形態では、証明データやヘッダ情報を検証要求ページ（図１０参照）に入力するという手間が着信者に発生し、また、後者の形態では、検証用ソフトを着信者端末２にインストールするという手間が着信者に発生することになり、発信者である企業にとっては、このような手間を顧客に強いることは好ましくない。なお、着信者の手間を軽減する手法として、Ｓ／ＭＩＭＥによる電子署名をメールに付加するという手法も考えられるが、この場合も、着信者はＳ／ＭＩＭＥ対応の電子メールソフトを着信者端末２にインストールする必要があり、発信者である企業にとっては、顧客が利用する電子メールソフトを特定のものに限定することになり好ましくない。

そこで、実施例３では、秘密情報として秘密鍵に代えてキーワードを規定しておき、メール中継者がかかるキーワードを証明コードとしてメールに挿入して着信者に転送する場合を説明する。ここで、実施例３で用いる「キーワード」とは、メールの発信者には知られておらず、メールの着信者のみが知っているキーワードのことであり、例えば、メール中継者と着信者との間で事前に決定される。このため、このキーワードがメール中継者から転送されてきたメールに挿入されていれば、着信者はキーワードを見ただけでメールの正当性を判別することができるようになる。

さらに、上記の実施例１では、発側メールサーバ３のＩＰアドレスに基づいてメールの正当性を判定する場合を説明したが、例えば、企業内の発側メールサーバ３に発信許可を与えているような場合には、企業内の同一ＬＡＮから「なりすましメール」が発信されると、これを正当なメールであると誤って判定してしまうという問題がある。

そこで、実施例３では、発信者を事前に認証した上で条件付きの許可証を発行し、かかる許可証が添付されたメールを発信者から受け付けてメールの正当性を判定する場合を説明する。ここで、実施例３で用いる「許可証（特許請求の範囲に記載の「許可情報」に対応する）」とは、メールの発信が許可されるために必要な有効条件を含んで生成されるものであり、例えば、発信者のユーザＩＤ、メールの発信が許可される有効期限、さらには、所定の鍵から定まる関数にユーザＩＤおよび有効期限を入力して得られる改ざん防止コードを含んで生成される。

［システムの概要および特徴（実施例３）］
続いて、図１４を用いて、実施例３に係るメール配送システムの概要および特徴を説明する。図１４は、実施例３に係るメール配送システムの概要を説明するための図である。

実施例３に係るメール配送システムにおいて、発着信者以外の第三者であるメール中継者は、メールの発信が許可される発信者のユーザＩＤおよびパスワードを対応付けて記憶する発信者認証情報記憶部、上記の仮ＩＤに対応付けて着信者の実アドレスを記憶する実アドレス記憶部、並びに、着信者の実アドレスに対応付けて上記のキーワードを記憶する秘密情報記憶部を有する。さらに、メール中継者は、上記した許可証（改ざん防止コード）の生成に用いる生成鍵および当該許可証の検証に用いる検証鍵を有する。

そして、許可証の生成を希望する発信者は、自己のユーザＩＤおよびパスワードをメール中継者に送信して、許可証の生成を要求する（図１４の（１）参照）。かかる許可証の生成要求を受け付けたメール中継者は、発信者認証として、ユーザＩＤおよびパスワードが発信者認証情報記憶部に記憶されているか否かを判定する（図１４の（２）参照）。その結果、発信者認証が成功（ＯＫ）した場合には、メールの発信が許可されるために必要な有効条件を含んだ許可証を生成する（図１４の（３）参照）。

具体的には、許可証の生成要求を受け付けた日時に所定の期間（例えば３ヶ月）を加えた日時を有効期限として設定した後、上記の生成鍵から定まる関数にユーザＩＤおよび有効期限を入力して改ざん防止コードを生成し、これらのユーザＩＤ、有効期限および改ざん防止コードからなる許可証を生成する。その後、メール中継者は、このようにして生成された許可証を発信者に通知する（図１４の（４）参照）。なお、発信者認証が失敗（ＮＧ）した場合には、メール中継者は、許可証を生成することなく、発信者認証が失敗した旨を含んだメッセージを発信者に通知する。

その一方、かかる許可証を受信した発信者は、着信者の実アドレスに対応する仮ＩＤを宛先アドレスとし、かつ、許可証が添付されたメールを発信する（図１４の（５）参照）。かかる許可証添付メールを受信したメール中継者は、このメールが発信を許可された正当なメールであるか否かを判定する（図１４の（６）参照）。具体的には、メールに添付された許可証からユーザＩＤ、有効期限および改ざん防止コードを取り出し、現日時が有効期限を経過していないかを判定するとともに、検証鍵から定まる関数にユーザＩＤおよび有効期限が入力して改ざん防止コードの正当性を検証する。その結果、現日時が有効期限の経過前であり、かつ、改ざん防止コードの正当性が認められれば、正当なメールである旨を判定する。

かかる判定で正当なメールである旨が判定された場合には、メール中継者は、メールの転送先となる着信者の実アドレスを取得する（図１４の（７）参照）。具体的には、メールの宛先アドレスに入力されている仮ＩＤに対応する実アドレスを実アドレス記憶部から取得する。なお、一つの仮ＩＤに対して複数の実アドレスが対応付けられている場合には、複数の実アドレスをそれぞれ取得する。

これに続いて、メール中継者は、発信者から発信されたメールが発信を許可された正当なメールである旨を証明する証明データを生成する（図１４の（８）参照）。具体的には、上記で取得した実アドレスに対応するキーワードを秘密情報記憶部から取得し、このキーワードを証明データとする。なお、上記で複数の実アドレスが取得された場合には、各実アドレスについて対応するキーワードを取得する。

その後、メール中継者は、メールの宛先アドレスを上記の実アドレスに置換するとともに、メールの本文末尾に証明データ（キーワード）を挿入し、かかるメールを着信者に転送する（図１４の（９）参照）。なお、現日時が有効期限の経過後であるか、改ざん防止コードの正当性が認められず、正当なメールではないと判定された場合には、メール中継者は、発信者から受信したメールを着信者に転送することなく破棄する。

このように、実施例３に係るメール配送システムでは、着信者が受け取る証明データ（を作成するための秘密情報（すなわち、キーワード）をメール中継者が発信者には知られない状態で管理するので、例えば、業務担当者の不正行為などによって証明データを生成するための秘密情報が漏洩するなど、発信者側から秘密情報が漏洩する可能性はなくなり、上記した実施例１と同様、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することが可能になる。

なお、実施例３に係るメール配送システムにおいては、上記の主たる相違点でも述べたように、メールに添付された許可証に基づいて正当なメールであるかを判定する点、着信者のみが知っているキーワードを証明データとして用いる点、実アドレスに代えて仮ＩＤを宛先アドレスとするメールを発信者端末１から受け付ける点等にも主たる特徴がある。

［システムの構成（実施例３）］
続いて、図１５を用いて、実施例３に係るメール配送システムの構成を説明する。図１５は、実施例３に係るメール配送システムの構成を示す図である。

同図に示すように、このメール配送システムは、発信者端末１と、着信者端末２と、発側メールサーバ３と、着側メールサーバ４と、許可証発行装置３０と、メール中継装置４０とを、ネットワーク（インターネット５、ＬＡＮ６、ルータＲ、ファイアウォールなどによって形成される通信網）を介して相互に通信可能に接続して構成される。以下に、各装置の役割や構成を説明する。

［発信者端末、着信者端末、発側メールサーバおよび着側メールサーバ（実施例３）］
このうち、発信者端末１、着信者端末２、発側メールサーバ３および着側メールサーバ４は、上記の実施例１で同様の符号を付して説明したものと、基本的に同様の役割を有するものである。ただし、実施例３において、発信者端末１には、少なくとも電子メールソフトおよびＷｅｂブラウザがインストールされ、着信者端末２には、少なくとも電子メールソフトがインストールされる。

そして、発信者端末１は、主として、許可証発行装置３０にアクセスして発信者認証要求に係るメッセージ（図２１参照）を送信する役割、生成された許可証を含んだ許可証通知メッセージ（図２３参照）を許可証発行装置３０から受信する役割、許可証が添付され、仮ＩＤを宛先アドレスとするメール（図２４参照）をメール中継装置４０に発側メールサーバ３を経由して送信する役割などを有する。一方、着信者端末２は、証明データ（キーワード）が挿入され、着信者のメールアドレスを宛先アドレスとするメール（図２７参照）をメール中継装置４０から着側メールサーバ４を介して受信する役割を有する。

［許可証発行装置（実施例３）］
次に、許可証発行装置３０は、上記した許可証を発行するサーバ装置であり、主として、発信者端末１から発信者の認証要求を受け付けて発信者認証を行う役割、許可証を生成する役割、許可証を発信者端末１に送信する役割などを有する。そして、この許可証発行装置３０は、本発明に密接に関連するものとして、図１５に示すように、ＨＴＴＰ通信部３１と、発信者認証情報記憶部３２と、発信者認証部３３と、許可証生成鍵記憶部３４と、許可証生成部３５とを備える。なお、許可証生成部３５は特許請求の範囲に記載の「許可情報生成手段」に対応する。

このうち、ＨＴＴＰ通信部３１は、いわゆるＨＴＴＰ（Hyper Text Transfer Protocol）等の通信プロトコルに従って、発信者端末１等との間における通信を制御する処理部である。具体的には、発信者端末１からアクセス要求メッセージを受信する処理、ユーザＩＤおよびパスワードを入力させる認証ファームからなるアクセス応答メッセージを発信者端末１に送信する処理、ユーザＩＤおよびパスワードからなる発信者認証要求メッセージ（図２１参照）を発信者端末１から受信する役割、許可証を含んだ許可証通知メッセージ（図２３参照）を発信者端末１に送信する処理などを実行する。

発信者認証情報記憶部３２は、正当な発信者を認証するための情報を記憶する手段である。具体的に説明すると、図１８は、発信者認証情報記憶部３２に記憶される情報の例を示す図であるが、同図に示すように、正当な発信者のユーザＩＤ（各利用者を一意に識別するためのＩＤ）と、各発信者のパスワードとを対応付けて記憶して構成される。

発信者認証部３３は、許可証の生成を要求してきた発信者が正当な発信者であるか否かを認証する処理部である。具体的に説明すると、図２１は、発信者端末１に表示される認証要求ページの例を示す図であるが、Ｗｅｂブラウザを用いて許可証発行装置３０にアクセスした発信者端末１のモニタ等には、同図に示すような「認証要求ページ」が出力され、かかるページに対して発信者のユーザＩＤおよびパスワードがキーボードやマウスを介して発信者から入力されると、発信者端末１は、これらの入力情報からなる発信者認証要求メッセージを許可証発行装置３０に送信する。そして、発信者認証部３３は、発信者認証要求メッセージに含まれるユーザＩＤおよびパスワードが発信者認証情報記憶部３２に対応付けて記憶されているか否かを検証し、両者が対応付けて記憶されている場合には、正当な発信者である旨を判定する。

許可証生成鍵記憶部３４は、許可証（より詳細には、許可書に含められる改ざん防止コード）の生成に用いる生成鍵（マスター鍵）を記憶する手段である。なお、この生成鍵は、後述するメール中継装置４０の許可証検証鍵記憶部４２に記憶される検証鍵と同一の鍵である。

許可証生成部３５は、発信者認証部３３によって正当な発信者である旨が認証された場合に、メールの発信が許可されるために必要な有効条件を含んだ許可証を生成する処理部である。具体的に説明すると、図２２は、許可証の生成を説明するための図であるが、同図に示すように、許可証の生成要求を受け付けた日時に所定の期間（例えば３ヶ月）を加えた日時を有効期限として設定した後、許可証生成鍵記憶部３４に記憶された生成鍵から定まる関数にユーザＩＤおよび有効期限を入力して改ざん防止コードを生成し、これらのユーザＩＤ、有効期限および改ざん防止コードからなる許可証を生成する。

なお、上述してきた許可証発行装置３０や後述するメール中継装置４０は、実施例１と同様、例えば、発信者端末１や発側メールサーバ３と同様の企業内に設定されて、一部のセキュリティ責任者のみが操作を許可されるように管理される。言い換えれば、一般の業務担当者が操作することができないように管理される。ただし、この実施形態は一例に過ぎず、データセンタ業者などの信頼ある別の業者が、許可証発行装置３０やメール中継装置４０を管理する実施形態であってもよい。

［メール中継装置（実施例３）］
続いて、メール中継装置４０は、発信者端末１から発信されたメールを中継して着信者端末２に配送するサーバ装置であり、主として、メールの発信者が知らない所定の秘密情報（キーワード）を記憶する役割、許可証が添付され、仮ＩＤを宛先アドレスとするメール（図２４参照）を発信者端末１から受信する役割、受信したメールが発信を許可された正当なメールであるか否かを判定する役割、仮ＩＤに対応する着信者の実アドレスを取得する役割、正当なメールである旨を証明するための証明データをキーワードで生成する役割、証明データ（キーワード）が挿入されたメール（図２７参照）を着信者端末２に転送する役割などを有する。

そして、このメール中継装置４０は、本発明に密接に関連するものとして、図１５に示すように、メール送受信部４１と、許可証検証鍵記憶部４２と、正当性判定部４３と、実アドレス記憶部４４と、実アドレス取得部４５と、秘密情報記憶部４６と、証明データ生成部４７と、転送処理部４８とを備える。なお、正当性判定部４３は特許請求の範囲に記載の「発信許可判定手段」に対応し、実アドレス記憶部４４は同じく「実アドレス記憶手段」に対応し、秘密情報記憶部４６は同じく「秘密情報記憶手段」に対応し、証明データ生成部４７は同じく「証明データ生成手段」に対応し、転送処理部４８は同じく「転送処理手段」に対応する。

このうち、メール送受信部４１は、いわゆるＳＭＴＰ（Simple Mail Transfer Protocol）等の通信プロトコルに従って、発信者端末１（より詳細には発側メールサーバ３）や着信者端末２（より詳細には着側メールサーバ４）等との間における通信を制御する処理部である。具体的には、発信者端末１から発信されたメール（図２４参照）を発側メールサーバ３経由で受信する処理、証明データが挿入されたメール（図２７参照）を着側メールサーバ４経由で着信者端末２に送信する処理などを実行する。

許可証検証鍵記憶部４２は、メールに添付された許可証（より詳細には、許可書に含まれる改ざん防止コード）の検証に用いる検証鍵を記憶する手段である。なお、この検証鍵は、上記した許可証発行装置３０の許可証生成鍵記憶部３４に記憶される生成鍵と同一の鍵である。

正当性判定部４３は、メールに添付された許可証に基づいて、発信者端末１から発信されたメールが発信を許可された正当なメールであるか否かを判定する処理部である。具体的に説明すると、図２５は、正当性判定（発信許可判定）を説明するための図であるが、同図に示すように、メールに添付された許可証にはユーザＩＤ、有効期限および改ざん防止コードが含まれる。そして、正当性判定部４３は、許可証から取り出した有効期限よりも現日時が経過していないかを判定するとともに、許可証検証鍵記憶部４２に記憶された検証鍵から定まる関数にユーザＩＤおよび有効期限が入力して改ざん防止コードを生成し、これが許可証に含まれる改ざん防止コードと一致するか否かを判定する。その結果、現日時が有効期限の経過前であり、かつ、改ざん防止コードの正当性が認められれば（改ざん防止コードが一致すれば）、正当なメールである旨を判定する。

実アドレス記憶部４４は、着信者の実アドレス（メールアドレス）を記憶する手段である。具体的に説明すると、図１９は、実アドレス記憶部４４に記憶される情報の例を示す図であるが、同図に示すように、仮ＩＤに対応付けて着信者の実アドレス（一または複数のメールアドレス）を記憶して構成される。ところで、この仮ＩＤは、例えば、業務マニュアルの配布などによって事前に発信者（業務担当者）に知らせておく必要がある。また、仮ＩＤの＠以降の文字列は、ＤＮＳ（Domain Name System）にＭＸレコードとして登録されており、このＭＸレコードに対応する装置としてメール中継装置４０のアドレスが登録されている。このように設定することによって、メールをメール中継装置４０に転送するルーチング設定を発側メールサーバ３に施す必要がなくなる。

実アドレス取得部４５は、正当性判定部４３によって正当なメールである旨が判定された場合に、メールの転送先である着信者の実アドレスを取得する処理部である。具体的に説明すると、図２６は、実アドレスの取得および証明データの生成を説明するための図であるが、同図に示すように、実アドレス記憶部４４は、メールの宛先アドレスに入力されている仮ＩＤに対応する実アドレスを実アドレス記憶部４４からそれぞれ取得する。

秘密情報記憶部４６は、メールの発信者が知らない所定の秘密情報であって、メールの着信者のみが知っているキーワードを記憶する手段である。具体的に説明すると、図２０は、秘密情報記憶部４６に記憶される情報の例を示す図であるが、同図に示すように、着信者の実アドレスに対応付けて各着信者のキーワードをそれぞれ記憶して構成される。ところで、このキーワードは、例えば、顧客がサービス加入時に任意のキーワードを選択してサービス加入申込書に記入し、このキーワードを企業が秘密情報記憶部４６に登録するようにしてもよく、あるいは、企業が顧客ごとにキーワードを選択し、これを顧客に伝えるとともに秘密情報記憶部４６に登録するようにしてもよい。なお、キーワードは必ずしも着信者（実アドレス）ごとに登録されている必要はなく、着信者や実アドレスで区別することなく共通のキーワードを登録しておいてもよい。

証明データ生成部４７は、正当性判定部４３によって正当なメールである旨が判定され、かつ、実アドレス取得部４５によってメールの転送先である着信者の実アドレスが取得された場合に、当該メールが発信を許可された正当なメールである旨を証明する証明データを生成する処理部である。具体的に説明すると、図２６は、実アドレスの取得および証明データの生成を説明するための図であるが、同図に示すように、証明データ生成部４７は、実アドレス取得部４５によって取得された実アドレスに対応するキーワードを秘密情報記憶部４６から取得して、このキーワードを証明データとする。

転送処理部４８は、証明データ生成部４７によって生成された証明データを正当なメールに挿入し、当該証明データが挿入されたメールをメール送受信部４１から着信者端末２（より詳細には着側メールサーバ４）に転送する処理部である。具体的に説明すると、図２７は、メール中継装置４０が転送するメールの例を示す図であるが、転送処理部４８は、メールの宛先アドレスを実アドレス取得部４５によって取得された実アドレスに置換するとともに、メールの本文末尾に証明データ（キーワード）を挿入し、このメールを転送する。なお、かかる転送に際しては、許可証が削除される。

［許可証の発行に至る処理（実施例３）］
続いて、図１６などを用いて、上記したメール配送システムにおける許可証の発行に至る処理の流れを説明する。図１６は、許可証の発行に至る処理の流れを示すシーケンス図である。

同図に示すように、許可証の発行を希望する発信者は、発信者端末１を介して許可証発行装置３０にアクセス要求メッセージを送信する（ステップＳ１６０１）。具体的には、発信者端末１のＷｅｂブラウザにおいて許可証発行装置３０のＵＲＬがアクセス先アドレスとして入力されると、発信者端末１は、許可証発行装置３０にアクセス要求メッセージをＨＴＴＰ要求の形式で送信する。

かかるアクセス要求メッセージを受信した許可証発行装置３０では、発信者のユーザＩＤおよびパスワードを入力させる認証フォームからなるアクセス応答メッセージを発信者端末１に送信する（ステップＳ１６０２）。具体的には、図２１に例示するように、ユーザＩＤの入力フィールド、パスワードの入力フィールド、送信ボタンおよびキャンセルボタンからなるＨＴＭＬページを発信者端末１に送信する。

これに対して、発信者端末１では、ユーザＩＤおよびパスワードからなる発信者認証要求メッセージを許可証発行装置３０に送信する（ステップＳ１６０３）。具体的には、アクセス応答メッセージを受信した発信者端末１のモニタ等には、図２１に例示したような「認証要求ページ」が出力されるが、かかるページに対してユーザＩＤおよびパスワードがキーボードやマウスを介して発信者から入力され、かつ、送信ボタンが押下されると、発信者端末１は、これらの入力情報からなる発信者認証要求メッセージを許可証発行装置３０に送信する。

そして、発信者端末１から発信者認証要求メッセージを受信した許可証発行装置３０は、発信者が正当な発信者であるか否かを認証する（ステップＳ１６０４）。具体的には、発信者認証要求メッセージに含まれるユーザＩＤおよびパスワードが発信者認証情報記憶部３２に対応付けて記憶されているか否かを検証し、両者が対応付けて記憶されている場合には、正当な発信者である旨を判定する。

このようにして発信者認証が成功すると、許可証発行装置３０は、メールの発信が許可されるために必要な有効条件を含んだ許可証を生成する（ステップＳ１６０５）。具体的には、許可証の生成要求を受け付けた日時に所定の期間（例えば３ヶ月）を加えた日時を有効期限として設定した後、許可証生成鍵記憶部３４に記憶された生成鍵から定まる関数にユーザＩＤおよび有効期限を入力して改ざん防止コードを生成し、これらのユーザＩＤ、有効期限および改ざん防止コードからなる許可証を生成する。なお、発信者認証が失敗した場合には、許可証発行装置３０は、許可証を生成することなく、発信者認証が失敗した旨を含んだメッセージを発信者に通知する。

その後、許可証を生成した許可証発行装置３０は、生成した許可証を含んだ許可証生成通知メッセージを発信者端末１に送信し（ステップＳ１６０６）、かかる許可証生成通知メッセージを受信した発信者端末１は、許可証生成通知メッセージに含まれる許可証を所定の記憶部に保存する（ステップＳ１６０７）。具体的には、許可証発行装置３０は、図２３に例示するような「許可証通知ページ」を発信者端末１に送信し、発信者端末１のモニタ等には同図に例示する「許可証通知ページ」が出力されるが、かかるページに対して「許可証．ｄｏｃ」がキーボードやマウスを介して発信者に押下されると、発信者端末１は、この許可証を所定の記憶部に保存する。

［メールの発信から受信に至る処理の流れ（実施例３）］
続いて、図１７などを用いて、上記したメール配送システムにおけるメールの発信から受信に至る処理の流れを説明する。図１７は、メールの発信から受信に至る処理の流れを示すシーケンス図である。

同図に示すように、メール中継装置４０は、許可証が添付され、仮ＩＤを宛先アドレスとするメールを発信者端末１から発側メールサーバ３を経由して受信する（ステップＳ１７０１）。具体的には、図２４は、発信者端末１から発信されるメールの例を示す図であるが、発信者端末１では、発信者アドレス（例えば、企業の業務担当者が顧客にメールを送信する際に用いるメールアドレス）がＦＲＯＭ欄に記載され、仮ＩＤがＴＯ欄に記載され、かつ、許可証発行装置３０から受け取った許可証が添付されたメールがキーボードやマウスを介して発信者によって作成されると、このメールを発側メールサーバ３に送信する。

かかるメールを受信したメール中継装置４０では、当該メールが発信を許可された正当なメールであるか否かを判定する（ステップＳ１７０２）。具体的には、図２５に例示したように、メールに添付された許可証から取り出した有効期限よりも現日時が経過していないかを判定するとともに、許可証検証鍵記憶部４２に記憶された検証鍵から定まる関数にユーザＩＤおよび有効期限が入力して改ざん防止コードを生成し、これが許可証に含まれる改ざん防止コードと一致するか否かを判定する。その結果、現日時が有効期限の経過前であり、かつ、改ざん防止コードの正当性が認められれば（改ざん防止コードが一致すれば）、正当なメールである旨を判定する。

このようにしてメールの正当性が判定されると、メール中継装置４０は、メールの転送先である着信者の実アドレスを取得する（ステップＳ１７０３）。具体的には、図２６に例示したように、メールの宛先アドレスに入力されている仮ＩＤに対応する実アドレスを実アドレス記憶部４４からそれぞれ取得する。これに続いて、メール中継装置４０は、メールが発信を許可された正当なメールである旨を証明する証明データを生成する（ステップＳ１７０４）。具体的には、図２６に例示したように、上記したステップＳ１７０３によって取得された実アドレスに対応するキーワードを秘密情報記憶部４６から取得して、このキーワードを証明データとする。

その後、メール中継装置４０は、証明データを正当なメールに挿入し、当該証明データが挿入されたメールを着側メールサーバ４に転送する（ステップＳ１７０５）。具体的には、メールの宛先アドレスを上記したステップＳ１７０３によって取得された実アドレスに置換するとともに、メールの本文末尾に上記したステップＳ１７０４によって生成した証明データ（キーワード）を挿入し、このメール（図２７参照）を着側メールサーバ４に転送する。なお、上記のステップＳ１７０２において、現日時が有効期限の経過後であるか、改ざん防止コードの正当性が認められず（改ざん防止コードが不一致）、正当なメールではないと判定されたメールについては、着信者（着側メールサーバ４）に転送されることなく破棄される。

一方、着側メールサーバ４は、上記した実施例１と同様、メール中継装置４０から受信した証明データ付きメールをメールボックスに保存する（ステップＳ１７０６）。そして、着信者端末２では、上記した実施例１と同様、任意のタイミングで（着信者の指示に応じて、もしくは、所定時間ごと定期的に）着側メールサーバ４に対してメール確認要求メッセージを送信する（ステップＳ１７０７）。

かかるメール確認要求メッセージを受信した着側メールサーバ４では、上記した実施例１と同様、メール確認応答として、メールボックスに到着しているメールを着信者端末２に送信する（ステップＳ１７０８）。その結果、証明データ（キーワード）が挿入されたメール（図２７参照）が着信者端末２のモニタ等に出力されることになる。そして、このキーワードは、上記したように、メールの発信者には知られておらず、メールの着信者のみが知っているものであるので、着信者はキーワードを見ただけでメールの正当性を判別することができる。つまり、メール中継者との間で事前に決定したキーワードがメールに挿入されていれば、「なりすましメール」ではない正当なメールであると判別できる。

［実施例３の効果等］
上述してきたように、実施例３によれば、着信者が受け取る証明データを作成するための秘密情報（すなわち、キーワード）をメール中継者が発信者には知られない状態で管理するので、例えば、業務担当者の不正行為などによって証明データを生成するための秘密情報が漏洩するなど、発信者側から秘密情報が漏洩する可能性はなくなり、上記した実施例１と同様、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することが可能になる。

また、実施例３によれば、メールとともに受け付けた許可証に含まれる有効条件（例えば、メールの発信が許可される期限）を満たすことを必要条件として正当なメールである旨を判定するので、メールの発信が許可されるために必要な有効条件を詳細に設定することで、正当なメールと判定できる範囲を実用的な範囲に制限することが可能になる。また、メールの発信が許可される期限を有効条件として規定することで、仮に許可証が漏洩した場合でも、漏洩による被害を一定期間内に留めることが可能になる。

また、実施例３によれば、着信者のみが知っている所定のキーワードを証明データとして用いるので、鍵を用いた証明データの生成に比較して、簡易に証明データを生成することが可能になる。また、着信者においては証明データを検証する処理が不要になるので、検証を実現するための機能（例えば、証明データ処理装置２０にアクセスするためのブラウザ、署名データの検証も行うメーラなど）を着信者端末２に用意する必要もなくなり、メールを着信できるメーラを用意するだけで、着信者は簡易にメールの正当性を判別することが可能になる。

また、実施例３によれば、着信者ごとに異なるキーワードを用いるので、証明データの偽造が困難になり、証明データの信頼性を高めることが可能になる。

また、実施例３によれば、実アドレスに代えて仮ＩＤを宛先アドレスとするメールを発信者端末１から受け付け、仮ＩＤに対応する実アドレスに宛先アドレスを置換してメールを転送するので、例えば、メールの発信者となる業務担当者などに対しては仮ＩＤのみを知らせ、着信者である顧客の実アドレスまでは知らせる必要がなくなり、業務担当者から顧客の実アドレスが漏洩する事態を防止することが可能になる。

さて、これまで実施例３に係るメール配送システムについて説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、図２８を用いて、以下では実施例４に係るメール配送システムとして、種々の異なる実施例を（１）〜（８）に区分けして説明する。なお、図２８は、実施例４に係るメール配送システムを説明するための図である。

（１）発信者認証
上記の実施例３では、ユーザＩＤおよびパスワードを用いて発信者認証を行う場合を説明したが、本発明はこれに限定されるものではなく、図２８に示すように、これに加えて、ユーザＩＤが無効化されていないことも必要条件にして発信者認証を行うようにしてもよい。すなわち、この場合には、不正行為などが原因で無効化されたユーザＩＤを記憶する無効化テーブルを許可証発行装置３０がさらに備え、発信者認証において、発信者から受け付けたユーザＩＤが無効化されたものであるか否かを無効化テーブルに基づいてさらに判定し、無効化されたユーザＩＤであれば、許可証を生成することなく、発信者認証が失敗した旨を含んだメッセージを発信者に通知する。なお、発信者認証の手法としては、上記したようなパスワード認証に限られず、ディジタル証明証、生体認証など、他のあらゆる認証方式を採用してもよい。

（２）許可証の生成方式
上記の実施例３では、いわゆるメッセージダイジェスト関数を用いて許可証を生成する場合を説明したが、本発明はこれに限定されるものではなく、例えば、図２８に示すように、公開鍵暗号化方式や共通鍵暗号化方式を用いて許可証を生成するようにしてもよい。具体的には、公開鍵暗号化方式や共通鍵暗号化方式を採用する場合には、例えばユーザＩＤおよび有効期限を秘密鍵で暗号化して暗号化データを生成し、この暗号化データを公開鍵（もしくは共通鍵）で復号化することによって暗号化データの正当性を検証する。

ところで、上記の実施例３では、許可証を用いてメールの正当性を判定する場合を説明したが、本発明はこれに限定されるものではなく、このような許可証を生成することなしに、発信者に発信許可を与えるようにしてもよい。つまり、例を挙げれば、上記した発信者認証を通じて正当な発信者であると認証された場合に、正当な発信者として認証された発信者の発信者端末１のＩＰアドレスおよび／または発信者アドレスを当該認証後の所定時間に限って有効なアドレスとしてメール中継装置３０（アドレス記憶手段）に記憶する。そして、発信者端末１からメールを受信すると、メール中継装置３０はメールから発信者端末１のＩＰアドレスおよび／または発信者アドレスを取得し、当該ＩＰアドレスおよび／または発信者アドレスがアドレス記憶手段に有効なアドレスとして記憶されていることを必要条件にして正当なメールである旨を判定する。

このように、メール発信に先立って発信者を認証した上で、正当な発信者として認証された発信者の発信者端末のＩＰアドレスや発信者アドレスを当該認証後の所定時間に限って有効なアドレスとして記憶しておき、メールから取得した発信者端末のＩＰアドレスや発信者アドレスが有効なアドレスとして記憶されていることを必要条件にして正当なメールである旨を判定するようにすれば、いわゆるパスワード認証や生体認証等の各種の認証手法を適宜採用して、不正な発信者を事前に排除することが可能になる。また、メールとともに許可情報（発信者認証が成功した旨を示す情報）を送信する手間を発信者に強いることなしに、不正な発信者を簡易に排除することが可能になる。

（３）有効条件
上記の実施例３では、メールの発信が許可される期限を有効条件として含んだ許可証を生成する場合を説明したが、本発明はこれに限定されるものではなく、図２８に例示するように、メール発信が許可される期間（例えば○年○月○日〜×年×月×日まで）、メール発信が許可される時間（例えば○時から○時まで）、メール発信が許可される発信者（例えば発信者のアドレス、発信者端末１のＩＰアドレスなど）、メール発信が許可される組織（例えばドメイン名）など、他の有効条件を指定するようにしてもよい。言い換えれば、同図に例示するように、発信者限定情報、有効期間（有効期限）、有効時間もしくはこれらの組合せを、有効条件として含んだ許可証を生成するようにしてもよい。

（４）暗号化対象
上記の実施例３では、許可証を暗号化する際に（より詳細には改ざん防止コードを生成する際に）、ユーザＩＤおよび有効期限を暗号化する場合を説明したが、本発明はこれに限定されるものではなく、図２８に示すように、ユーザＩＤや有効条件（上記した発信者限定情報、有効期間、有効時間もしくはこれらの組合せ）の一部または全てを暗号化することで改ざん防止コード（もしくは暗号化データ）を生成するようにしてもよい。

（５）メールの正当性判定
上記の実施例３では、許可証に含まれる有効条件（有効期限）を用いてメールの正当性を判定する場合を説明したが、本発明はこれに限定されるものではなく、図２８に示すように、許可証に含まれるユーザＩＤを用いて、かかるユーザＩＤが無効化されていないことも必要条件にしてメールの正当性を判定するようにしてもよい。すなわち、この場合には、不正行為などが原因で無効化されたユーザＩＤを記憶する無効化テーブルをメール中継装置４０がさらに備え、メールの正当性判定において、許可証に含まれるユーザＩＤが無効化されたものであるか否かを無効化テーブルに基づいてさらに判定し、無効化されたユーザＩＤであれば、メールは正当でない旨を判定する。このようにすれば、仮に許可証が漏洩した場合でも、発信者ＩＤを無効化リストに登録するだけで、公開鍵証明機関などを介することなく容易に許可証を無効化することも可能になる。

（６）ログ収集
上記の実施例３では、メールの転送処理に際して何らのログも収集することなくメールを転送する場合を説明したが、本発明はこれに限定されるものではなく、メールの転送処理に際してログを収集するようにしてもよい。すなわち、メール中継装置４０では、メールを転送する際に、メールのヘッダ情報および許可証に含まれるユーザＩＤをログとして収集するようにしてもよい。このようにすれば、例えば、どのようなメールが業務担当者から顧客に転送されたかを示すログが残るので、業務担当者による不正行為を抑止することが可能になる。

（７）ＦＲＯＭアドレスの置換
上記の実施例３では、メールの転送処理に際してＦＲＯＭアドレス（発信者アドレス）を維持したままメールを転送する場合を説明したが、本発明はこれに限定されるものではなく、ＦＲＯＭアドレスを別アドレスに置換した上でメールを転送するようにしてもよい。具体的に説明すると、例えば、転送メールのＦＲＯＭアドレスに記入する別アドレスを仮ＩＤに対応付けて記憶する別アドレス記憶部をメール中継装置４０がさらに備え、発信者である業務担当者に対しては、顧客にメールを送信する際に用いる実アドレス（図６や図２４に例示したＦＲＯＭアドレス）のみが知らされ、転送メールのＦＲＯＭアドレスに記入される別アドレスは秘密にされる。

そして、メール中継装置４０では、メール転送処理において、メールの宛先アドレスに入力されていた仮ＩＤに対応する別アドレスを別アドレス記憶部から取得し、メールのＦＲＯＭアドレスを実アドレスから別アドレスに置換した上でメールを転送する。なお、ここでは、仮ＩＤと発信者の別アドレスとを対応付けて別アドレス記憶部に記憶させる場合を説明したが、発信者の実アドレスと別アドレスとを対応付けて記憶し、メールのＦＲＯＭアドレスに入力されていた実アドレスに対応する別アドレスを別アドレス記憶部から取得して置換するようにしてもよい。

このように、発信者の実アドレスに代わる別アドレスを用意し、転送するメールのＦＲＯＭアドレスを別アドレスに置換してメールを転送するようにすれば、例えば、メールの発信者となる業務担当者などに対して実アドレスのみを知らせ、着信者である顧客の目に触れる別アドレスまでは知らせないようにすることができ、これによって、別アドレスを用いたメールを不正に生成することが困難になり、この観点からも「なりすましメール」の発生を防止することが可能になる。

また、このようなＦＲＯＭアドレスの置換を行う場合には、メールの着信者ごとに異なる別アドレスを生成するようにしてもよい。すなわち、例を挙げれば、別アドレス記憶部から取得した別アドレスにおけるユーザ名部分の末尾に、着信者の実アドレス（転送されるメールの宛先アドレス）を所定の鍵付きハッシュ関数に入力して得られる着信者固有の値を追加し、かかる着信者ごとに生成される別アドレスに置換してメールを転送する。このように、着信者ごとに異なる別アドレスを生成するようにすれば、別アドレスの偽造が困難になり、「なりすましメール」の発生を一層防止することが可能になる。

（８）システム構成等
上記の実施例３で図示した各装置（例えば、図１５に例示した許可証発行装置３０、メール中継装置４０など）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、許可証発行装置３０およびメール中継装置４０を一体として構成するなど、各装置の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、上記の実施例３で説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報（例えば、メールや画面表示の内容等）については、特記する場合を除いて任意に変更することができる。

なお、上記の実施例３では、本発明を実現する各装置（例えば、許可証発行装置３０、メール中継装置４０など）を機能面から説明したが、各装置の各機能はパーソナルコンピュータやワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。すなわち、本実施例１で説明した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータ上で実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。つまり、例を挙げれば、実施例３に示したような許可証発行装置用プログラムや、メール中継装置用プログラムを格納したＣＤ−ＲＯＭ（装置ごとに別個のＣＤ−ＲＯＭであってもよい）を配布し、このＣＤ−ＲＯＭに格納されたプログラムを各コンピュータが読み出して実行するようにしてもよい。

以上のように、本発明に係るメール配送システム、メール配送方法、メール配送プログラムおよびメール中継装置は、発信者端末から発信されたメールを中継して着信者端末に配送する場合に有用であり、特に、発信者側から秘密情報（署名鍵など）が漏洩する可能性をなくし、かかる秘密情報の漏洩に起因した「なりすましメール」の発生を防止することに適する。

実施例１に係るメール配送システムの概要を説明するための図である。 実施例１に係るメール配送システムの構成を示すブロック図である。 メールの発信から受信に至る処理の流れを示すシーケンス図である。 証明データの検証に至る処理の流れを示すシーケンス図である。 発信許可情報記憶部に記憶される情報の例を示す図である。 発信者端末から発信されるメールの例を示す図である。 メール中継装置が受信するメールの例を示す図である。 証明データの生成を説明するための図である。 メール中継装置が転送するメールの例を示す図である。 着信者端末に表示される検証要求ページの例を示す図である。 証明データの検証を説明するための図である。 着信者端末に表示される検証結果通知ページの例を示す図である。 実施例２に係るメール配送システムを説明するための図である。 実施例３に係るメール配送システムの概要を説明するための図である。 実施例３に係るメール配送システムの構成を示すブロック図である。 許可証の発行に至る処理の流れを示すシーケンス図である。 メールの発信から受信に至る処理の流れを示すシーケンス図である。 発信者認証情報記憶部に記憶される情報の例を示す図である。 実アドレス記憶部に記憶される情報の例を示す図である。 秘密情報記憶部に記憶される情報の例を示す図である。 発信者端末に表示される認証要求ページの例を示す図である。 許可証の生成を説明するための図である。 発信者端末に表示される許可証通知ページの例を示す図である。 発信者端末から発信されるメールの例を示す図である。 正当性判定（発信許可判定）を説明するための図である。 実アドレスの取得および証明データの生成を説明するための図である。 メール中継装置が転送するメールの例を示す図である。 実施例４に係るメール配送システムを説明するための図である。

符号の説明

１ 発信者端末
２ 着信者端末
３ 発側メールサーバ
４ 着側メールサーバ
５ インターネット
６ ＬＡＮ（Local Area Network）
１０ メール中継装置
１１ メール送受信部
１２ 発信許可情報記憶部
１３ 正当性判定部
１４ 秘密情報記憶部
１５ 証明データ生成部
１６ 転送処理部
２０ 証明データ処理装置
２１ ＨＴＴＰ通信部
２２ 検証用情報記憶部
２３ 証明データ検証部
３０ 許可証発行装置
３１ ＨＴＴＰ通信部
３２ 発信者認証情報記憶部
３３ 発信者認証部
３４ 許可証生成鍵記憶部
３５ 許可証生成部
４０ メール中継装置
４１ メール送受信部
４２ 許可証検証鍵記憶部
４３ 正当性判定部
４４ 実アドレス記憶部
４５ 実アドレス取得部
４６ 秘密情報記憶部
４７ 証明データ生成部
４８ 転送処理部

Claims (13)

1. 発信者端末から発信されたメールを中継して着信者端末に配送するメール配送システムであって、
   前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段と、
   前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手段と、
   前記発信許可判定手段によって正当なメールであると判定された場合に、当該メールが正当なメールである旨を証明するための証明データとして、前記データ記憶手段に記憶されたデータを取得する証明データ取得手段と、
   前記証明データ取得手段によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手段と、
   を備えたことを特徴とするメール配送システム。
2. 前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、
   前記証明データ取得手段は、前記メールの着信者ごとに対応するデータを取得することを特徴とする請求項１に記載のメール配送システム。
3. 前記メールの発信が許可される発信者端末または発側メールサーバのＩＰアドレスを記憶するＩＰアドレス記憶手段をさらに備え、
   前記発信許可判定手段は、前記メールから発信者端末または発側メールサーバのＩＰアドレスを取得し、当該ＩＰアドレスが前記ＩＰアドレス記憶手段に記憶されていることを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする請求項１または２に記載のメール配送システム。
4. 前記メールの発信が許可されるために必要な有効条件を含んだ許可情報を生成する許可情報生成手段をさらに備え、
   前記発信許可判定手段は、前記許可情報生成手段によって生成された許可情報を前記メールとともに前記発信者端末から受け付け、前記メールが前記許可情報に含まれる有効条件を満たすことを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする請求項１または２に記載のメール配送システム。
5. 正当な発信者として認証された発信者の発信者端末のＩＰアドレスおよび／または発信者アドレスを当該認証後の所定時間に限って有効なアドレスとして記憶するアドレス記憶手段をさらに備え、
   前記発信許可判定手段は、前記メールから発信者端末のＩＰアドレスおよび／または発信者アドレスを取得し、当該ＩＰアドレスおよび／または発信者アドレスが前記アドレス記憶手段に有効なアドレスとして記憶されていることを必要条件にして前記メールが正当なメールである旨を判定することを特徴とする請求項１または２に記載のメール配送システム。
6. 前記発信者端末から発信されるメールは、前記メールの着信者の実アドレスに代えて当該実アドレスを識別するための仮ＩＤを含んだメールであって、
   前記メールの着信者の実アドレスおよび当該実アドレスを識別するための仮ＩＤを対応付けて記憶する実アドレス記憶手段をさらに備え、
   前記転送処理手段は、前記実アドレス記憶手段に記憶された実アドレスのなかから前記メールに含まれる仮ＩＤに対応する実アドレスを取得し、当該実アドレスを宛先として前記メールを転送することを特徴とする請求項１〜５のいずれか一つに記載のメール配送システム。
7. 前記転送処理手段は、前記メールの発信者の実アドレスに代わる別アドレスを生成し、前記メールの発信元を当該別アドレスに置換して転送することを特徴とする請求項１〜６のいずれか一つに記載のメール配送システム。
8. 前記転送処理手段は、前記発信者の別アドレスとして、前記メールの着信者ごとに異なる別アドレスを生成することを特徴とする請求項７に記載のメール配送システム。
9. 発信者端末から発信されたメールを中継して着信者端末に配送するメール中継装置であって、
   前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段と、
   前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手段と、
   前記発信許可判定手段によって正当なメールであると判定された場合に、当該メールが正当なメールである旨を証明するための証明データとして、前記データ記憶手段に記憶されたデータを取得する証明データ取得手段と、
   前記証明データ取得手段によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手段と、
   を備えたことを特徴とするメール中継装置。
10. 発信者端末から発信されたメールを中継して着信者端末に配送するメール配送方法であって、
    前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定工程と、
    前記発信許可判定工程によって正当なメールであると判定された場合に、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段から、当該メールが正当なメールである旨を証明するための証明データとして、データを取得する証明データ取得工程と、
    前記証明データ取得工程によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理工程と、
    を含んだことを特徴とするメール配送方法。
11. 前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、
    前記証明データ取得工程は、前記メールの着信者ごとに対応するデータを取得することを特徴とする請求項１０に記載のメール配送方法。
12. 発信者端末から発信されたメールを中継して着信者端末に配送するメール配送方法をコンピュータに実行させるメール配送プログラムであって、
    前記発信者端末から発信されたメールが当該発信を許可された正当なメールであるか否かを判定する発信許可判定手順と、
    前記発信許可判定手順によって正当なメールであると判定された場合に、前記メールの発信者には知られておらず、前記メールの着信者のみが判別可能に知っているデータを記憶するデータ記憶手段から、当該メールが正当なメールである旨を証明するための証明データとして、データを取得する証明データ取得手順と、
    前記証明データ取得手順によって取得された証明データを前記正当なメールに挿入し、当該証明データが挿入されたメールを前記着信者端末に転送する転送処理手順と、
    をコンピュータに実行させることを特徴とするメール配送プログラム。
13. 前記データ記憶手段は、前記メールの着信者ごとに異なるデータを記憶するものであって、
    前記証明データ取得手順は、前記メールの着信者ごとに対応するデータを取得することを特徴とする請求項１２に記載のメール配送プログラム。