JP2006185124A - 漏洩元特定可能メールアドレス構成方法およびそれを利用した漏洩元特定可能メール送受信方法とそのシステム - Google Patents

Abstract

【課題】現状のメールシステムと親和性を持ち、かつメールアドレスの漏洩元を特定することができるメール送受信方法、メール送受信システムを提供すること。
【解決手段】受信者の識別子と送信者の識別子を受信者のメールサーバに送信する段階と、メールサーバが受信者の識別子と送信者の識別子とメールサーバが発行したノンスに前記メールサーバのみが知る秘密鍵で暗号化した値を計算して受信者に送信する段階と、前記暗号化した値に受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する段階を含む、メールアドレス構成方法をとる。さらに、前記メールアドレス構成方法で構成したメールアドレスを送信者に送信する段階を含む、メール送信方法をとる。
【選択図】図１

Description

本発明は、漏洩元特定可能メールアドレス構成方法に関し、特にそれを利用した漏洩元を特定可能メール送受信方法とそのシステムに関する。

近年個人情報の漏洩が大きな社会問題となっており、個人情報保護が叫ばれるようになってきた。個人情報の保護には、様々な手段があるが、情報漏洩源の特定は個人情報流出の抑止力となる。メールアドレスの漏洩には、通信路上における盗聴によることが考えられ、これに対処するためにSSLなど通信路の暗号化が利用されてきた。一方で、アドレスを入手した人間がアドレスを人為的に漏洩（データクリープ）している可能性もあり、これらは通信路の暗号化など既存のセキュリティーシステムによって防ぐことはできない。このような情報漏洩元を特定する方法の１つとして染色メール(E-mail Dyeing)が知られている。

染色メールは、従来のメールシステムの拡張によりメールアドレスの漏洩元を特定可能にするシステムである。メールサーバreceiver.comを利用するユーザAのメールアドレスを[email protected], メールサーバーsender.comを利用するユーザBのメールアドレスを[email protected], メールサーバsender2.comを利用するユーザCのメールアドレスを[email protected]とする。AとBがコンタクトを取るときは、下記のアドレスを利用する。
・ A→B [email protected]
・ B→A [email protected]
また同様にAがCとコンタクトを取るときは
・ A→C [email protected]
・ C→A [email protected]
BやCがAに送るときに用いるアドレスを染色メールアドレスと呼ぶ。ただしAは自ら[email protected]などの染色メールアドレスを管理する必要はなく、Aのメールサーバreceiver.comは通信相手に応じて下記のアドレスと染色メールアドレスの変換表を用いて通信を行う。

Aからの送信時にはFrom:欄を通信相手に応じて変換し、Aの真のアドレスを秘匿する。Aの受信時にはTo: 欄のアドレスから、本来のアドレスに、変換表を用いて変換する。このとき、もし未知の宛先(例えばC以外)から、[email protected]宛てにメールが届いた場合、Cが[email protected]を漏洩したと特定することができる。

しかしながら、染色メールでは、通信経路上でメールアドレスが漏洩した場合、必ずしもその染色アドレスの利用者Bがメールアドレスを漏洩したとは限らない。また染色メールではメールサーバにおいて、メールアドレスがN個存在し、各メールアドレスが平均Ｍ個の宛先について通信を行っている場合、宛先と染色メールアドレスの変換表に要するヒープ使用量はＯ(NM)であり、染色メールアドレスと送り主の変換にはＮ×Ｍの表の探索をしなければならない。さらに染色メールは、少なくともAがBを知っているケースにおいてのみ実現可能であり、Aの知らないB側からメールアドレスを求めるようなプロトコルは存在しない。従って、B側からのコンタクトには現状のメールシステムにおけるメールアドレスを使用せざるを得ず、Aが選択的に通信許可を出すようなことができない。

従って、本発明が解決しようとする課題は、メールアドレス漏洩されたかどうかを確実に知るメールアドレスの構成方法を提供することである。
また別の課題は、メールアドレスの漏洩がその利用者により漏洩されたかどうかを確実に知るメールアドレスの構成方法を利用したメール送信システムを提供することである。
また別の課題は、メールアドレスの利用者による漏洩があった場合に、その利用者が誰か、すなわち漏洩元を特定することができるメールアドレス構成方法または、その方法を利用したシステムを提供することである。
また別の課題は、漏洩元特定のために使用する計算資源が非常に少ないメール送受信方法、またはその方法を利用したシステムを提供することである。
また別の課題は、お互いにメールアドレス漏洩に対して責任追及を伴う通信要求が行える、対称なメールアドレスの交換を可能とするメール送受信方法、またはメールシステムを提供することである。
また別の課題は、現状のメールシステムと親和性を持ち、かつメールアドレスの漏洩元を特定することができるメール送受信方法、メール送信システムを提供することである。

上記課題を解決するために、本発明は、受信者の識別子Aと送信者の識別子Bを受信者のメールサーバAMSに送信する段階と、メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者に送信する段階と、前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する段階を含む、メールアドレス構成方法をとる。
さらに、受信者の識別子Aと送信者の識別子BをAのメールサーバAMSに送信する段階と、メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスをNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者Aに送信する段階と、前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する段階と、前記構成したメールアドレスを送信者に送信する段階を含む、メールアドレス送信方法をとる。

また別の態様として、受信者の公開アドレスを公開する段階と、前記公開アドレスと、送信者との通信許可を依頼するメッセージM_Bを、送信者のメールサーバBMSを経由して受信者のメールサーバAMSに送信する段階と、メールサーバAMSはM_Bを受信者に送信する段階と、前記メッセージを読み取った受信者からのアドレス配布許可をメールサーバAMSが受け取る段階と、メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNにメールサーバAMSの秘密鍵Kで暗号化した値{A,B,N}Kを計算してメールサーバBMSを経由して送信者に送信する段階と、送信者が前記暗号化した値に受信者のドメイン名を付与してメールアドレス（LDアドレス）を構成し受信者にメールを送る段階を含む、メール送信方法をとる。

本発明によれば、利用する通信路は何らかの方法で暗号化されており、通信路上において第三者の盗聴は不可能であるため、メールアドレスが漏洩した場合、BMSが信頼できる限り、漏洩した者Bを特定できる。またBMSが信頼できない場合において、第三者が新鮮なタイムスタンプを含む暗号化LDアドレス用いてメールを送るならば漏洩元をBと特定することができる。また暗号化LDアドレスを利用することでBMSからLDアドレスが直接漏洩することを防ぐことができる。タイムスタンプを利用することにより暗号化LDアドレスの漏洩（BMSからの漏洩）とLDアドレス（Bからの漏洩）の漏洩を区別することができる。ユーザ(受信者)がLDアドレスを目にする機会はあるがそのアドレスを記録しておく必要はない。ユーザ（受信者）はLDアドレスについて一切知る必要がなくあたかも一般のメールが送られてきたようにすることができる。メールサーバにおいてヒープ使用量はメールサーバの公開鍵暗号に利用する秘密鍵、公開鍵と秘密鍵暗号の秘密鍵の分のみであるため計算資源が非常に少なくできる。またLDアドレスと送信元の変換に要する時間は、BMSが信頼できる場合は秘密鍵暗号の復号コストであるし、BMSが信頼できない場合は公開鍵暗号と秘密鍵暗号の復号コストの和となりスケーラブルである。またLDアドレス伝達用のアドレスを用意することで、任意のBからのメールアドレス（LDアドレス）要求に対してAの判断でそのアドレス配布の可否を選択することができる。これによりB側からもAに対してLDアドレス（漏洩に対して責任追及を伴うアドレス）での通信を要求するといったような、対称なメールアドレスの交換も可能となる。本発明は従来技術に比べて空間計算量、時間計算量、セキュリティという三つの観点で優位である。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが本発明の解決手段に必須であるとは限らない。

＜定義＞
始めに用語を以下のように定義する。また本発明において利用する通信路は、全て何らかの方法で暗号化されており、通信路上において第三者の盗聴は不可能であるものとする。
・通信相手 A, B（各図ではAが受信者、Bが送信者）
・Aが利用するメールサーバ AMS (ドメイン名receiver.com)
・Bが利用するメールサーバ BMS (ドメイン名sender.com)
・Aのメールアドレス [email protected]
・Bのメールアドレス [email protected]
・AMSの秘密鍵暗号方式の秘密鍵 K_AM
・AMSが発行するノンス N (ノンスとは同じ目的のために１度しか使用されない値を指す)
・AMSの公開鍵暗号方式の公開鍵 K_AMP
・Bの公開鍵暗号方式の公開鍵 K_BP
・To:欄とは宛先欄のことである。
・From:欄とは送信者欄のことである。

＜アドレス構成法＞
送信者Bが受信者Aに送信するときのメールアドレスを{A,B,N} K_AM@receiver.comとする。ここでアドレスに使われているA, BはそれぞれA,Bの識別子であるものとする。ただし、括弧書の {*}K は "*" を鍵Kで暗号化することを表すものとする。以後このように構成されたメールアドレスを Leakage Detectable メールアドレスと呼ぶ。もしここで、AおよびBのユーザーネームのみを用いて{A,B}K_AM@receiver.comとしてLDアドレスを構成した場合、解読の危険性が高い。そこで暗号文の冗長性を高めるためにノンスを用いている。B以外からこのメールアドレスを用いてメールが送られてきた場合、アドレス自体にBの情報が含まれているので、AMS（またはA）は、Bがメールアドレスを漏洩したことを特定できる。また本発明の Leakage Detectable メールアドレス (以降LDアドレスと記載する)を用いた本発明のメールシステムをLDMSと簡略して記載する。なおノンスには例えばその瞬間の日付時刻（タイムスタンプ）や何らかの目的のために１度だけ使用される特殊な値などを用いる。

＜LDアドレスの構成例＞
本発明で使用する暗号化方法について本発明の本質を逸脱することなく種々選択可能であるが、例えば公開鍵暗号方式において素数p=1231, q=4567を用いたRSAで暗号化した場合の例を示す。[email protected], [email protected], [email protected]において、[email protected] を受信者とするLDアドレスは、
{1011}_RSA= 4011665より、[email protected] (10が11から受信するアドレス)
{1012}_RSA= 5595442より、[email protected] (10が12から受信するアドレス)
などとなる。ここで {*}_RSA は素数p,qに基づく公開鍵暗号による暗号化を意味する。染色メールで利用される[email protected],[email protected]などの単純なルールによるアドレス生成はアドレスの変換ルールが極めて見破られやすいが、暗号化によるLDアドレス生成の場合、計算量的に変換ルールの看破は困難である。上記のアドレス構成方法をハードウェアで実現しメールアドレス構成システムとしてもよい。

＜アドレス配布プロトコル＞
現状のメールシステムでは、BがAにメールを送るには、BがAのメールアドレスを知る必要がある。本発明の場合も同様に、BがAにメールを送るには、BがAのLDアドレスを知る必要がある。しかし、本発明の目的（漏洩元特定）を達成するためには、任意の相手にLDアドレスを公開することはできない。そこで、ここでは、特定の（Aが認めた）相手にだけLDアドレスを公開する方法を記す。また、現状のメールシステムでは、メールアドレスを特定の相手にのみ伝えて運用することもできるし、不特定多数の相手に公開して運用することも可能である。このような現状のメールシステムの利便性を損なわないために、本発明のLDアドレスの配布方法は、この両者に対応したものとなっている（後者は不特定多数にアドレスを公開する場合ではあるが、不特定多数の中からLDアドレスを公開する相手を選択する）。本発明のメールアドレス配布方法は、Aがメールアドレスを渡す相手を選択できる。つまり、Aがなんらかの形でB（アドレスを渡す相手）を認証するプロセスが必要になる。ここでは、AがBを直接認証するケースと、BからAに依頼して認証を行う2つのケースについて説明する。

・AがBを直接認証するケース
Aからアドレスを配布する場合のアドレス配布プロトコルを図１に示す。Aの識別子（メールアドレスのアカウント名など）をA、Bの識別子をBとすると、まずAがAMSに対して、A、Bを送る（１１０）。次にそれを受け取ったAMSは、LDアドレス（{A, B, N}K_AM）を構成し、Aに返す（１２０）。図１ではAがBにメール以外の手段でLDアドレスを教えている方法が示している（１３０）が、AMSが直接BにLDアドレスを知らせるようにしてもよい。このとき、AとAMS、AとBの通信は暗号化などの方法を用いて安全に行われるものとする。

・BからAに依頼して認証を行うケース１
BMSが信頼できる場合のアドレス配布プロトコルを図２に示す。図１の配布プロトコルの場合ではあらかじめAがBを知っていなければならず、B側からアプローチする方法がない。AがBを知らない場合、Bから自分の認証をAに要求する方法が必要となる。その問題を解決するための配布プロトコルが図２である。まず、Aは、A_pub@receiver.comを公開しておく（これを公開LDアドレスと呼ぶ）（２１０）。次に Bは公開されたA_pub@receiver.comに対して、Bとの通信許可を依頼するメッセージM_Bを送信する（図中では、BMSを経由してAMSに送信される）（２２０）。次にこのメッセージを受け取ったAMSはM_BをAに渡す（２４０）。次に Aはこの内容を判断してLDアドレスの配布許可（decision）をAMSに送る（２５０）。次に Decisionが許可（true）であった場合には、LDアドレス（{A, B, N}K_AM）をBに送る（２６０、２７０）。最後に Bは今後このLDアドレス（{A, B, N}K_AM@receiver.com）を用いてAにメールを送る。このとき、各通信は暗号化などの方法により安全に行われるものとする。

・BからAに依頼して認証を行うケース２
BMSが信頼できない場合のアドレス配布プロトコルを図３に示す。図２のプロトコルでは、BMSがLDアドレス（{A, B, N}K_AM）を知ることができるので、BMSが信頼できない状況下では、LDアドレスの漏洩が発生した場合に、このLDアドレスの漏洩元がBMSなのか、Bなのか特定できなくなってしまう。BMSがBと同じ責任領域に存在する場合（例えば、BMSもBも会社B’の管理下にある場合など）はこれで問題ない。しかし、BMSとBの責任領域が異なる場合、例えばBMSがインターネットサービスプロバイダ(ISP)によって運用され、Bがそのユーザである場合などは、漏洩元がどちらなのかを特定する必要がある。この問題を解決する方法が図３である。図３の３１０〜３５０までは、図２の２１０〜２５０と同じであるが、AMSがBMSにLDアドレスを伝える際（３６０）に、LDアドレスをBの公開鍵（K_BP）で暗号化して伝える。こうすることにより、BMSにはLDアドレス本体を知られることなくBにLDアドレスを伝える（３７０）ことができる。

＜メール送受信プロトコル＞
送信者BにAへのLDアドレス{A,B,N}K_AM@receiver.comが前述のアドレス配布プロトコルで安全に送られているものとする。またここで、AのメールサーバAMSは、AのLDアドレス{A,B,N}K_AM@receiver.comおよび秘密鍵K_AMを第三者に漏洩しないことを前提とする。

・BMSが信頼できる場合
BMSが信頼できる場合とは、BMSによる{A,B,N}K_AM@receiver.comの第三者への漏洩の危険性がない場合をさす。図４にBからAへのメール送信プロトコルを示す。まず BはBMSに{A,B,N}K_AM@receiver.comのアドレスを用いてメッセージMを送る（４１０）。次に BMSはAMSに{A,B,N}K_AM@receiver.comのアドレスを用いてメッセージMを送る（４２０）。最後に AMSは秘密鍵暗号の秘密鍵K_AMを用いて{A,B,N}K_AMからAを得て、AにメッセージMを送る（４３０）。このプロトコルにおいて、BMSおよびAMSは{A,B,N}K_AM@receiver.comを漏洩しないことが前提となっているため、漏洩の可能性があるのはBのみである。Bによる{A,B,N}K_AM@receiver.comの漏洩があり，{A,B,N}K_AM@receiver.comを用いてメールが送られてきた場合、AMSはこれを復号しBを得るため、送信者毎に異なるLDアドレスを与えている限りAは自分のLDアドレスの漏洩元を特定できる。

・BMSが信頼できない場合
図５にBMSが信頼できない場合のメール送信プロトコルを示す。まず BはAMSの公開鍵K@yAMP@zとタイムスタンプTを用いて暗号化LDアドレス{{A,B,N}K@yAM@z, T}K@yAMP@z @receiver.comを構成し、BMSに{{A,B,N}K@yAM@z, T}K@yAMP@z @receiver.com のアドレスを用いてメッセージMを送る（５１０）。このように作られたアドレスを暗号化LDアドレスと呼ぶ。次に BMSはAMSに{{A,B,N}K@yAM@z, T}K@yAMP@z @receiver.comのアドレスを用いてメッセージMを送る（５２０）。最後に AMSはAMSの公開鍵K@yAMP@zおよび秘密鍵暗号の秘密鍵K@yAM@zおよび公開鍵暗号の秘密鍵K@yAMS@zを用いて{{A,B,N}K@yAM@z, T}K@yAMP@z @receiver.comからAを得て、AにメッセージMを送る（５３０）。ただしタイムスタンプTが、現在時刻から有効期間Lを引いた時間より前である（タイムスタンプが古い）場合、AにメッセージMを送信しない。または、タイムスタンプが古いことをAに告げる。このプロトコルにおいて、AMSは{A,B,N}K@yAM@[email protected]を漏洩しないことが前提となっているため、メールアドレスを漏洩する可能性があるのはBおよびBMSである。このとき、BはLDアドレス{A,B,N}K@yAM@[email protected]を知っているが、BMSはそれを知らない。BMSが知りえるのは暗号化LDアドレス{{A,B,N}K@yAM@z, T}K@yAMP@[email protected]のみである。従って、漏洩元特定に関して以下のことが言える。新鮮なタイムスタンプTを使って暗号化LDアドレス{{A,B,N}K@yAM@z, T}K@yAMP@[email protected]を作成することができるのは、{A,B,N}K@yAM@zを知っている者のみである。従って、新鮮なタイムスタンプを含んだ暗号化LDアドレスで第三者からメールが送られてきた場合、漏洩元はBと特定できる。逆に古いタイムスタンプを含んだ暗号化LDアドレスで第三者からメールが送られてきた場合、漏洩元の一意な特定はできない。これは BがLDアドレスを漏洩し、漏洩先が古いタイムスタンプを使って暗号化LDアドレスを構成し、Aにメールを送信した場合と、BMSが暗号化LDアドレスを漏洩し、漏洩先がそのアドレス使ってAにメールを送ってきた場合との判別ができないためである。この場合、AMSは、そのような（タイムスタンプが古い）メールをAに送らないようにするか、または、Aに対して漏洩の可能性があることを示唆するなどして対応することができる。なおBMSが信頼できる場合も上記タイムスタンプTを用いて暗号化LDアドレス{{A,B,N}K@yAM@z, T}K@yAMP@z @receiver.comを構成することも当然ながら有効である。

図６にBがAにメールを送る場合の（BMSが信頼できる場合）のフローチャートを示す。まずステップ６１０で、Bは、Aから受け取ったアドレス{A, B, N}[email protected]宛てにメールを送る。次にステップ６２０でBからAあてのメールを受け取ったBMSは、そのメールをAMS（ドメイン名receiver.com）に送信する。そしてステップ６３０でメールを受け取ったAMSは、アカウント部{A, B, N}kを、AMSの鍵kで復号し、A, Bを得る。メールのFrom欄と、アカウント部復号により得られたBを比較して、両者が一致しているなどにより、メールアドレスの漏洩の可能性が検知されなければ、ステップ６４０でAにメールを送信しステップ６６０でAがメールを受信する、一方、メールのFrom欄とアカウント部復号により得られたBを比較して、両者が異なっている場合など、メールアドレスの漏洩の可能性を検知した場合には、ステップ６５０で例外処理を行う。この例外処理は、漏洩したアドレスに基づく第３者からのメールと判断してAにメールを送信しない、Aに警告通知と共にメールを送信する、Aのメールアドレスを使用不可にするなど対策を講じる。

以下実際のLDアドレスの配布、LDアドレスを用いたメールの送受信、本発明のLDMSを応用した実施例を示す。

＜LDアドレスの配布＞
AがBに物理的に直接メールアドレスを配布する場合には、Aが自分の連絡先を教える際に、まず Bのメールアドレスを聞く。次にそのBのメールアドレスを（携帯メールなどで）AMSに送信する（１１０）。AMSから作成されたLDアドレスが（携帯メールなどに）返る（１２０）。最後に AはこのLDアドレスをBに直接教える（１３０）。
AがBにメールで連絡先を教える場合には、AがBに連絡先を教える際に、まず、BのメールアドレスをAMSに送る（１１０）。 AMSはLDアドレスを作成し、AにメールでLDアドレスを送る（１２０）。最後に Aは、BにメールでLDアドレスを送る（このときこのメールは暗号化しておく）（１３０）
Aが公開LDアドレスを自分のホームページ公開している場合には、まず、AがA_pub@receiver.comを自分のホームページに公開LDアドレスとして公開しておく（２１０または３１０）。それを見たBはA_pub@receiver.com宛てに、LDアドレスを要求する旨を記したメッセージM_Bを送る（２２０、２３０または３２０、３３０）。AMSはM_BをAに送信する（２４０または３４０）。次に AはM_B からBに対してLDアドレスを与えるかを判断し、LDアドレス発行の可否をAMSに送る（２５０または３５０）。最後に AMSは、このアドレスを漏洩しないようにという旨のメッセージとともに、LDアドレスをBにメールで送る（２６０、２７０または３６０、３７０）。
AがBに直接連絡先を教える場合には、Aは自分の名刺などにA_pub@receiver.comを記し、Bに配る（２１０または３１０）。次に BはA_pub@receiver.comに一度メールを出す（２２０、２３０または３２０、３３０）。以後は、上記ホームページの公開の実施と同じである。

＜LDアドレスを用いたメールの送受信＞
（１）BMSが信頼できる場合、Bは、LDアドレスをTo欄に書き、メールを送る（４１０、４２０）。AMSは、LDアドレスを復号して得られるBと、メールのFrom欄の値を比較し、それらが一致した場合、正しい送信者から送信されてきたメールであると判断し、メールの本文をAに送る（４３０）。BとFrom欄の値が一致しなかった場合、メールアドレス漏洩検出の旨をAに伝える。この場合、LDアドレスに含まれるBに制約がある。また、第三者CがFrom欄をBとしてメールを送ってきた場合にはAMSではアドレス漏洩を検出できないが、メッセージの内容などから、Aが漏洩を判断することもできる。
（２）BMSが信頼できる場合、Bは、LDアドレスをTo欄に書き、メールを送る（４１０、４２０）。AMSは、LDアドレスを復号し、LDアドレスに含まれるBとメッセージとFrom欄の内容をAに送信する（４３０）。それらを受け取ったAは、識別子BとFrom欄、メッセージの内容などから、このメールアドレスが漏洩していないことを確認する。仮に第三者Cからのメールであれば、識別子Bで表されるBはメールアドレスを漏洩したことになる。この場合、LDアドレスに含まれる識別子Bに制約はなく、Aが判断できる内容であればよい。
（３）BMSが信頼できない場合、Bは、LDアドレスをToに書き、メールの送信ボタンを押す。それと同時にメーラがAMSから公開鍵K_AMPを取得し、現在の時間をタイムスタンプとして暗号化LDアドレスを作成し、To欄をこの暗号化LDアドレスで書き換えてBMSに送る（５１０）。BMSは暗号化LDアドレスを用いてAMSにメールを送る（５２０）。メールを受け取ったAMSは暗号化LDアドレスを復号し、タイムスタンプを調べる。
（３−１）タイムスタンプが、現在時刻から有効期間Lを引いた時間よりも後である（つまりタイムスタンプが新鮮な）場合、LDアドレスを復号し、識別子Bから、LDアドレスの漏洩があるかをチェックする。このチェックの方法は、上記（１）または（２）いずれかの方法で行う。
（３−２）タイムスタンプが、現在時刻から有効期間Lを引いた時間よりも前である（つまりタイムスタンプが失効している）場合、このアドレスの有効期間が過ぎており、メッセージがAに届かなかった旨を、BMSを通してBに伝える。
（４）BMSが信頼できない場合、上記（３）の場合の（３−１）までは同様に行い、上記（３−２）の、タイムスタンプが失効している場合において、暗号化LDアドレスの復号、LDアドレスの復号を行い、LDアドレスの漏洩をチェックする。このチェックの方法は、上記（１）または（２）のいずれかの方法で行う。最後にAMSはタイムスタンプが失効しているので、暗号化LDアドレスが漏洩している可能性がある旨をAに伝える。

＜From詐称対策＞
現在のメールシステムにおいては、From欄を実際の差出人のメールアドレスとは異なる文字列にすることができる。本発明のメールシステムを利用することで、From欄を書き換えたメールを自動的にブロックする、またはそれに対する警告を出すことができる。以下にその手順を示す。まず LDアドレスを構成する際に必要となるB（メール送信者）の識別子を、Bのメールアドレス（[email protected]）とする。つまりこのとき構成されるLDアドレスは {A,B,N}[email protected]となる。A（メールの受信者）またはAMSが、送られてきたメールのLDアドレスを復号する際に、送られてきたメールのFrom欄と、LDアドレスに含まれているBの識別子（[email protected]）を比較し、それが異なっていたら受信を拒否またはその旨を警告する。こうすることで、例えばBがウィルスに感染し、ウィルスがFrom欄を詐称してBのアドレス帳にあるAの（LD）アドレスにメールを送った場合に、Aはこのようなメールを受信せずに済む。また受信拒否のかわりに警告を発することで、ユーザ自信がfrom詐称かどうかを判断することも可能である。

＜携帯電話メールにおけるLDアドレスの利用＞
携帯電話を介したメール交換においては、様々な迷惑メールが問題となっている。その一つは携帯電話のメールアドレスが漏洩し、そのあて先に迷惑メールが送られてくるケースである。この場合、携帯電話のメールアドレスを本発明のプロトコルでLDアドレスに変換し、これを用いることで、万が一漏洩し、迷惑メールが到達した場合には漏洩元特定が可能である。また他の送信者にはアドレス変更を伝えることなくこのアドレスでメールを受け取らないよう設定することで、迷惑メールを受信拒否することが可能である。
もう一つのケースは、メールアドレスの漏洩先が、任意の第三者に迷惑メールを送信し、その際に、送信元を漏洩したメールアドレスを用いて偽るケースである。たとえば、自分のメールアドレスを[email protected],漏洩先を [email protected],漏洩先が迷惑メールを送るあて先を[email protected],[email protected],... などとする。このとき、漏洩先の迷惑メール送信者は
To:[email protected]
From:[email protected]
などとすることで、[email protected]を隠蔽し、送信者が[email protected]であるかのように身分をいつわる。この際に、もしも[email protected]が存在しないメールアドレスだった場合、この迷惑メールはあて先不明メールとなるため、[email protected]はこの迷惑メールが送信されなかったというメッセージをメールサーバから受信する。このとき、[email protected]がもし{1011}_RSA= 4011665からなるLDアドレス[email protected] を用いていた場合、アドレス漏洩先である[email protected]が特定される。[email protected]が迷惑メール送信者か、単なる漏洩者かの特定はできないが、少なくとも、[email protected]の漏洩が原因で迷惑メールが発生したことを特定することができる。また、From欄が[email protected] であるメールの受信拒否を行うことで、あて先不明メールの差し戻しのメッセージを受け取らずにすむといったメリットがある。

＜ISPによるメールアドレスの漏洩検知サービス＞
メールサービスを提供しているInternet Service Provider(ISP)は、そのメールシステムにLDMSを採用することで、その利用者に、メールアドレスの漏洩検知を通知するサービスを提供することができる。以下にその方法を示す。ここでISPのメールサーバはサーバ固有の秘密鍵Kを保持しているものとする。
・ユーザAがユーザBにメールを送る場合は、ISPはユーザAにメールアドレス[email protected]を発行し、サーバ側に保管する。ユーザAは識別子Aを秘密にしておく必要がある。AがユーザBにメールを送る場合、Aはメールクライアントソフト上で、To欄にBのメールアドレス[email protected]を書くが、ISPのメールサーバはFrom欄をLDアドレス｛A,B, N}[email protected]に自動的に書き換え、メールを送信する。
・ユーザBがユーザAにメールを送る場合は、BがAあてのLDアドレスを用いてAにメールを送信する。それを受け取ったサーバはLDアドレスをKで復号し、Aの識別子を得て、BからのメールのTo欄をA＠ISP.comに書き換える。AはBからのメールをメールサーバから受信する。
・ユーザAのメールアドレスが漏洩した場合は、BがAのLDアドレスをCに漏洩し、CがAの漏洩アドレスを利用してAに迷惑メールを送る。ISPはCから受信したLDアドレスを復号することで、それがAあてであることと、そのLDアドレスがBに発行されたものであることを検出する。そしてCから受信したメールのFrom欄とLDアドレスから抽出したLDアドレスの本来の所持者を比較して、これが異なる場合、本来の所持者（B）が、LDアドレスを漏洩した可能性があることをAに警告する。
このサービスでは、AはLDアドレス（{A, B, N}[email protected]など）を直接管理する必要がないという利点がある。サーバプログラムがLDアドレスへの変換を行い、LDアドレスをAに対して隠蔽しているため、AはTo、From欄ともに通常の識別子によるメールアドレスを利用すればよい。また上記は、From欄がB以外の者によって詐称されていた場合でも有効に働く。本発明はアドレス生成ルールに暗号を利用しているため、秘密鍵の漏洩がない限り偽造は困難である。またLDアドレスの生成およびLDアドレスから真の識別子の抽出は符号化・復号化プロセスによって定数時間で実行可能である。また符号化・復号化プロセスに利用するメモリ量は通常問題にならないくらい小さい。従って空間計算量が定数で、時間計算量も定数である本発明はこのようなサービスに非常に適している。

＜一般ユーザに配慮した利用＞
暗号化されたアドレスを一般ユーザが扱わなくて済むようにした拡張されたプロトコルを図７〜９を用いて説明する。LDアドレスの使用においてはメール送受信の際に、暗号化された複雑なアドレスを取り扱う場合が生じる。ISPの実施例の項で述べた方法を利用すれば、A（LDアドレスの宛先となるのユーザ）はLDアドレスを直接扱わずに済むようにできる。しかし、B（LDアドレスを使ってAにメールを送るユーザ）には、暗号化され、複雑な見た目のLDアドレスを直接扱う場合もある。そこで一般ユーザへの配慮として内部はLDアドレスでも外見は通常のメール形態と同様にする方法を以下に説明する。
ここでは、メールを受け取るユーザ（つまりLDアドレスの宛先となるユーザ）をA、Aのメーラを受信者のメーラAML、AのメールサーバをAMS、Aに発行されるAの真のアドレスを[email protected]とし、メールを送るユーザ（つまりLDアドレスを使ってAにメールを送るユーザ）をB、BのメーラをBML、BのメールサーバをBMS、Bのアドレスを[email protected]とする。また、このとき、Aは、Bのメールアドレス（[email protected]）を何らかの方法で（BがLDMSを利用しているとすれば、そのプロトコルを利用して）あらかじめ知っているものとする。
この方法はAがBにメールを送ることによってそのFrom欄から相手にアドレスが伝わる際に、Bが暗号化された文字列（LDアドレス）を直接扱う必要をなくすというものである。そこでBの使用するメーラBMLに、本システムに対応するための拡張を加える。一方で、その他のプロトコルやシステムは変更する必要が無い。
現在のメールシステムでは、送信されるメールのヘッダに、いくつかのフィールドが存在する。送信者フィールド(From:フィールド)は、そのヘッダに含まれるフィールドの一つで、ここにメールの送信者（本来の意味ではメールを書いた人）のアドレスが記されることになる。従って、LDMSにおいては、Aの送るメールのFrom欄には、少なくともAMSからメールが送られる際には{A, B, N}[email protected]のような、暗号化されたアドレスが記される。これがそのままBに送信されると、Bはこの複雑なアドレスを直接目にすることになる（図１〜５の通常プロトコルを参照）。そこで現状のメールシステムのメールヘッダに存在する、ユーザ拡張フィールドを利用することで、この問題を解決する。そのユーザ拡張フィールドをX-From:フィールドとする。（現行のメールシステムにおいて、ユーザ拡張フィールドはX-から始まる。また、他のユーザ拡張フィールドとの干渉を避けるために、X-LDMSFromなどでも良いが、長いのでここではX-Fromとする）。以下のこの拡張されたプロトコルの詳細を説明する。

＜拡張されたプロトコル＞
まず、AMSがAに対してメールアカウントを発行する際に、実際のアドレス[email protected]以外に、Q_Aという、AMS下でAに一意なAの別名であるニックネーム（愛称、あだ名でもよい）も生成する（７０１）。このQ_Aは、AMS下の他のユーザと干渉しなければ、Aが選択してもかまわない。つまりこのQ_AはAMS以下のユーザに重複がないようにAに一意に設定さる別名で、BMLにX-From の内容が登録される際にAMS下の他のユーザとアドレスの干渉が発生しないことを保証する。
・AがBにメールを送ることにより、BにAのアドレスが伝わる際の拡張プロトコル
図７にAがBにメールアドレスを配布する拡張プロトコルを示す。Aは、AMLのTo:欄にBのアドレス[email protected]を記して、メールを送信する（７１０）。このとき、AMLは、From:欄に[email protected]を設定し、AMSにメールを送信する（７２０）。これは通常のメールシステムのプロトコルそのものである。それを受け取ったAMSは、LDアドレス{A, B, N}[email protected]を生成し、From:欄をLDアドレスに書き換える。更に、AMSは、ユーザ拡張フィールドX-From:を作成し、そこにAの別名であるQ_A@ams.comを書き込む。このようにして出来上がったメールをBMSに送信する（７３０）。このプロトコルは、本発明独自のプロトコルである。それを受け取ったBMSは、Bにメールを送信する（７４０）。これは通常のメールシステムのプロトコルそのものである。BML（７５０）は、送信されたメールを受け取る。ここで、BML（７５０）が、LDMSのために拡張されている場合、BMLは、X-From:フィールドを解釈して、X-From:フィールドの内容をキー、From:フィールドの内容（LDアドレス）を値(Value)とするテーブルを作成する（７０２）。以後、ここで作成されるテーブルを別名テーブル（ニックネームテーブル）と呼ぶことにする。そして、メールヘッダーのFrom:フィールドをX-Fromフィールドの内容（つまり別名Q_A@ams.com）に書き換えてユーザに提示する（７６０）。こうすることで、ユーザBは、LDアドレスを直接扱う必要がなくなる。BML（７５０）がLDMSのための拡張がなされていない場合、BMLは、X-From:フィールドを解釈することはできないので、LDアドレスがそのままFrom:フィールドの内容として、ユーザに提示されてしまう。しかしながらLDアドレスのために拡張を施していないメーラでもLDアドレスのメールを扱うことはできる。
・BがAにメールを送る際の拡張プロトコル
図８にBがAにメールを送る拡張されたプロトコルを示す。ここでは、BMLがLDMSのために拡張されており、上記プロトコルによってBはAのアドレスがQ_A@ams.comであるかのように見えているものとする。この状態で、Bは、BMLを用いて、Aにメールを送ろうとする。この際、BにはAのアドレスがQ_A@ams.comであるように見えているので、BMLのメール編集画面のTo:欄に、Q_A@ams.comを入力し、BMLに送信命令を出す（８１０）。送信命令を受けたBMLは、別名テーブルから、Q_A@ams.comを検索し、その値（つまりLDアドレス）をTo:欄に上書きし、そのメールをBMSに送信する（８２０）。ここから先は、これまでに説明した本発明のプロトコルと全く同一である。

＜拡張プロトコルの例外処理＞
この拡張プロトコルにおいて、通常のLDMS利用時よりも、Bが知りうる情報として、別名Q_A@ams.comが新たに増えた。しかしながら、このQ_A@ams.comは漏洩しても特に問題のない情報である。なぜなら、Q_A@ams.comに対してメールを送信したとしても、Q_A@ams.comに対応するユーザは存在しない。また、もしAMSがLDMSのプロトコルに従い、Q_Aを復号しようとしても、その復号結果は意味をもたず、Q_AがLDアドレスでないことを確認できる。更に、例えば別名の生成に、あるルールを設けてやれば、AMSがそのルールを解釈し、別名を使ってメールが送信されていることを把握することができる。そうすることで、このメールが正当な方法で送信されていないこと、つまり通常のメールシステムにおけるアドレスでのメール送信や、LDMSのプロトコルに従ったメール送信でないことを判別することができる。その判断を元に、Aに警告を添えてメールを送る、あるいは、監査用のアカウントにメールを送信するなど、例外処理を行うことができる。図９にBがCへ、別名を漏洩した場合を示す。Bから知らされたAへのアドレスを使ってCがAにメールを送る（９０２）。第３者CのメールサーバCMSからAMSへメールが送信されると、AMSは、Q_Aの鍵kによる復号を試みるが、結果は理解できないものになる。そこで、AMSは元のアカウント部のQ_Aを理解できるため、この情報を元に、Cは正統なメール送信者でないことを知り、監査用アカウントにメールを送ったり、Aに警告と共にメールを送信したりするなどの例外処理をすることができる（９０１）。BMLを逆アセンブルしてLDアドレスを取得された場合、BMLは別名テーブルの中に、LDアドレスを保存している。BMLがテーブルの暗号化などを行い、LDアドレスがなるべく外部に漏れないようにするという方法も考えられる。万一このテーブルの情報が外部に漏れた際には、この拡張プロトコルを使わない場合の、LDアドレスが漏洩した場合と等価である。

＜通常のメールとの共存＞
BMLが通常の（本発明の方法を使用しない）メールを受け取った場合、受信したメールのX-From:フィールドがないことで、そのメールが通常のメールであると理解することができる。その場合、From:フィールドの内容を、キー、値の両方として別名テーブルに登録してもよいし、何も登録しなくてもよい。BMLを使ってメールを送信する際には、From:フィールドに相当するエントリーがあれば、その値をTo:欄に上書きするが、相当するエントリーがなければTo:欄はそのままでBMSにメールを送る。また、正当なユーザであっても、違うメーラでQ_A@ams.comを使ってメール送ることはできない。この場合、違うメーラがLDMSに対応しているメーラであれば、テーブルをエクスポートできるようにするなどで対策可能である。

＜ハードウェア構成例＞
図１０に本実施例又はその応用例に係るメールサーバおよびユーザ使用端末のハードウェア構成の一例を示す。コンピュータ１０００は、ホストコントローラ９１０により相互に接続されるＣＰＵ９００、ＲＡＭ９４０、ＲＯＭ９３０及びＩ／Ｏコントローラ９２０を有するＣＰＵ周辺部と、Ｉ／Ｏコントローラ９２０により接続される通信インターフェイス９５０、ハードディスクドライブ９８０、及びＣＤ/ＤＶＤ等の円盤型メディア９９５を読み書きできるマルチコンボドライブ９９０、フレキシブルディスク９８５を読み書きできるＦＤドライブ９４５、サウンド入出力装置９６５を駆動するサウンドコントローラ９６０、表示装置９７５を駆動するグラフィックコントローラ９７０を備える。

ＣＰＵ９００は、ＲＯＭ９３０、ＢＩＯＳ及びＲＡＭ９４０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ９７０は、ＣＰＵ９００等がＲＡＭ９４０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置９７５上に表示させる。もしくはグラフィックコントローラ９７０がＣＰＵ９００等が生成する画像データを格納するフレームバッファをその内部に含んでもよい。

通信インターフェイス９５０は、ネットワークを介して外部のメールサーバ、ユーザ端末、ルータ等と通信する。なおネットワークは有線、無線、赤外線、ＢＬＵＥＴＯＯＴＨ等の近距離無線で接続しても本願の構成を何ら変更することなく利用可能である。ハードディスクドライブ９８０は、コンピュータ１０００が使用するメーラアプリケーション、サーバプログラム等のコード及びデータを格納する。マルチコンボドライブドライブ９９０は、ＣＤ／ＤＶＤ等のメディア９９５からプログラム又はデータを読み取り、これら記憶装置から読み取られたプログラム、データはＲＡＭ９４０にロードされＣＰＵ９００により利用される。本発明のプログラム記録した媒体はこれらの外部記憶メディアから供給されてもよいし、内部のハードディスクドライブ９８０やネットワークを通じてダウンロードして供給されてもよい。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを取り込んでもよい。上記の構成の一例から理解されるように、本発明に必要なハードウェアは通常のコンピュータ機能を有するものは如何なるものでも利用可能である。例えばモバイル端末、携帯端末、通信機能を備えた家電、メール送受信専用のハードウェアでも何らの支障なく利用可能である。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

Aからアドレスを配布する場合のアドレス配布プロトコル示す図である。 BMSが信頼できる場合のアドレス配布プロトコルを示す図である。 BMSが信頼できない場合のアドレス配布プロトコルを示す図である。 BMSが信頼できる場合のBからAへのメール送信プロトコルを示す図である。 BMSが信頼できない場合のメール送信プロトコルを示す図である。 BMSが信頼できる場合のBがAにメールを送る場合のフローチャートを示す図である。 AがBにメールアドレスを配布する拡張プロトコルを示す図である。 BがAにメールを送る拡張されたプロトコルを示す図である。 BがCへ、別名を漏洩した場合を示す図である。 本発明に利用するハードウェア構成の一例を示す図である。

符号の説明

９１０ ホストコントローラ
９００ ＣＰＵ
９４０ ＲＡＭ
９３０ ＲＯＭ
９２０ コントローラ
９５０ 通信インターフェイス
９８０ ハードディスクドライブ
９９５ 円盤型メディア
９９０ マルチコンボドライブ
９８５ フレキシブルディスク
９４５ ドライブ
９６５ サウンド入出力装置
９６０ サウンドコントローラ
９７５ 表示装置
９７０ グラフィックコントローラ
９９０ マルチコンボドライブドライブ
９９５ メディア
１０００ コンピュータ
１０９０ フレキシブルディスク
１０９５ ＣＤ−ＲＯＭ

Claims (22)

1. 受信者の識別子Aと送信者の識別子Bを受信者のメールサーバAMSに送信する段階と、
   メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者に送信する段階と、
   前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する段階
   を含む、メールアドレス構成方法
2. 送信者が受信者にメールを送信する方法であって、
   受信者の識別子Aと送信者の識別子Bを受信者のメールサーバAMSに送信する段階と、
   メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスをNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者に送信する段階と、
   前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する段階と、
   前記構成したメールアドレスを送信者に送信する段階
   を含む、メール送信方法。
3. 受信者の公開アドレスを公開する段階と、
   前記公開アドレスと、送信者との通信許可を依頼するメッセージM_Bを、送信者のメールサーバBMSを経由して受信者のメールサーバAMSに送信する段階と、
   メールサーバAMSがM_Bを受信者に送信する段階と、
   前記メッセージを読み取った受信者からのアドレス配布許可をメールサーバAMSが受け取る段階と、
   メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNにメールサーバAMSの秘密鍵Kで暗号化した値{A,B,N}Kを計算してメールサーバBMSを経由して送信者に送信する段階と、
   前記暗号化した値に受信者のドメイン名を付与してメールアドレス（LDアドレス）を構成し受信者にメールを送る段階
   を含む、メール送信方法。
4. 受信者の公開アドレスを公開する段階と、
   前記公開アドレスと、送信者との通信許可を依頼するメッセージM_Bを、送信者のメールサーバBMSを経由して受信者のメールサーバAMSに送信する段階と、
   メールサーバAMSはM_Bを受信者に送信する段階と、
   前記メッセージを読み取った受信者からのアドレス配布許可をメールサーバAMSが受け取る段階と、
   メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNにメールサーバAMSの秘密鍵Kで暗号化しさらに送信者の公開鍵K_BPで暗号化した値{{A,B,N}K}K_BPを計算してメールサーバBMSを経由して送信者に送信する段階と、
   を含む、メール送信方法。
5. メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与した受信者のメールアドレス（LDアドレス）を、送信者が知っている場合において、
   メールサーバBMSが前記メールアドレスとメッセージMを送信者から受信する段階と、
   メールサーバBMSがメールサーバAMSに前記メールアドレスにメッセージMを送信する段階と、
   メールサーバAMSが秘密鍵K_AMを用いて前記メールアドレスから受信者を特定し、該受信者にメッセージMを送る段階
   を含む、メール送信方法。
6. メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与したメールアドレス（LDアドレス）を、送信者が知っている場合において、
   前記暗号化した値{A,B,N}KとタイムスタンプTに受信者の公開鍵で暗号化した値{{A,B,N}K_AM, T}K_AMPに受信者のドメイン名を付与したメールアドレスを構成し、メッセージMを送る段階と、
   メールサーバBMSがメールサーバAMSに前記メールアドレスを用いてメッセージMを送る段階と、
   メールサーバAMSがメールサーバAMSの公開鍵K_AMPおよび秘密鍵K_AMおよび秘密鍵K_AMSを用いて受信者を特定し、受信者にメッセージMを送る段階
   を有する、メール送信方法。
7. 前記タイムスタンプTが、現在時刻から有効期間Lを引いた時間より前である場合、受信者にメッセージMを送信しないか、若しくはタイムスタンプが古いことを受信者に知らせる段階を有する、請求項６に記載の方法。
8. 受信者のメーラAMLの宛先欄に送信者のアドレスが入力されたことに応答して、受信者のメーラAMLが、送信者欄に受信者のメールアドレスを設定し、メールサーバAMSにメールを送信する段階と、
   メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与したメールアドレス（LDアドレス）を生成し、送信者欄を前記LDアドレスに書き換える段階と、
   メールサーバAMSがユーザ拡張フィールドを作成するか、あるいは受信者がユーザ拡張フィールドを作成することに応答して、メールサーバAMSが受信者の別名を該ユーザ拡張フィールドに書き込む段階と、
   メールサーバAMSが、前記ユーザ拡張フィールドを有するメールをメールサーバBMSに送信する段階と、
   メールサーバBMSが、送信者にメールを送信する段階と、
   送信者のメーラBMLが、送信されたメールを受け取る段階と、
   送信者のメーラBMLが、前記ユーザ拡張フィールドを解釈して、前記ユーザ拡張フィールドの内容をキー、送信者フィールドの内容を値とするテーブルを作成する段階と、
   送信者のメーラBMLが、送信者フィールドを前記ユーザ拡張フィールドの内容に書き換えてユーザに提示する段階と
   を有する、メール送信方法、
9. 前記メール送信方法がさらに、送信者から受信者へメールの送信にあたり、
   宛先欄に入力された受信者のメールアドレスを前記テーブルを参照して対応する値を得る段階と
   前記値を宛先欄に上書きする段階と、
   前記メールをメールサーバBMSに送信する段階
   を有する請求項８に記載の方法。
10. 送信者から知らされた受信者へのLDアドレスを使って第３者が受信者にメールを送る段階と、
    第３者のメールサーバCMSからメールサーバAMSへメールが送信される段階と
    メールサーバAMSが、前記メールのアカウント部を復号する段階と、
    メールの送信者欄の情報と、前記復号により得られた情報を比較して、両者が一致しているか否かを判断する段階
    を有する、請求項２〜９に記載の方法。
11. 前記比較の結果が一致していない場合、前記第３者が正統なメール送信者でないと判断し、前記LDアドレスを使用不可にするか、または受信者にメールを送信しないか、または受信者に警告通知を行う段階
    をさらに有する、請求項１０に記載の方法。
12. 受信者の識別子Aと送信者の識別子Bを受信者のメールサーバAMSに送信する手段と、
    メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者に送信する手段と、
    前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する手段
    を含む、メールアドレス構成システム
13. 送信者が受信者にメールを送信するメールシステムであって、
    受信者の識別子Aと送信者の識別子Bを受信者のメールサーバAMSに送信する手段と、
    メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスをNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kを計算して受信者に送信する手段と、
    前記暗号化した値{A,B,N}Kに受信者のドメイン名を付与して送信者が受信者にメールを送るメールアドレス（LDアドレス）を構成する手段と、
    前記構成したメールアドレスを送信者に送信する手段
    を含む、メールシステム。
14. 受信者の公開アドレスを公開する手段と、
    前記公開アドレスと、送信者との通信許可を依頼するメッセージM_Bを、送信者のメールサーバBMSを経由して受信者のメールサーバAMSに送信する手段と、
    メールサーバAMSがM_Bを受信者に送信する手段と、
    前記メッセージを読み取った受信者からのアドレス配布許可をメールサーバAMSが受け取る手段と、
    メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNにメールサーバAMSの秘密鍵Kで暗号化した値{A,B,N}Kを計算してメールサーバBMSを経由して送信者に送信する手段と、
    前記暗号化した値に受信者のドメイン名を付与してメールアドレス（LDアドレス）を構成し受信者にメールを送る手段
    を含む、メールシステム。
15. 受信者の公開アドレスを公開する手段と、
    前記公開アドレスと、送信者との通信許可を依頼するメッセージM_Bを、送信者のメールサーバBMSを経由して受信者のメールサーバAMSに送信する手段と、
    メールサーバAMSはM_Bを受信者に送信する手段と、
    前記メッセージを読み取った受信者からのアドレス配布許可をメールサーバAMSが受け取る手段と、
    メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNにメールサーバAMSの秘密鍵Kで暗号化しさらに送信者の公開鍵K_BPで暗号化した値{{A,B,N}K}K_BPを計算してメールサーバBMSを経由して送信者に送信する手段と、
    を含む、メールシステム。
16. メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与した受信者のメールアドレス（LDアドレス）を、送信者が知っている場合において、
    メールサーバBMSが前記メールアドレスとメッセージMを送信者から受信する手段と、
    メールサーバBMSがメールサーバAMSに前記メールアドレスにメッセージMを送信する手段と、
    メールサーバAMSが秘密鍵K_AMを用いて前記メールアドレスから受信者を特定し、該受信者にメッセージMを送る手段
    を含む、メールシステム。
17. メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与したメールアドレス（LDアドレス）を、送信者が知っている場合において、
    前記暗号化した値{A,B,N}KとタイムスタンプTに受信者の公開鍵で暗号化した値{{A,B,N}K_AM, T}K_AMPに受信者のドメイン名を付与したメールアドレスを構成し、メッセージMを送る手段と、
    メールサーバBMSがメールサーバAMSに前記メールアドレスを用いてメッセージMを送る手段と、
    メールサーバAMSがメールサーバAMSの公開鍵K_AMPおよび秘密鍵K_AMおよび秘密鍵K_AMSを用いて受信者を特定し、受信者にメッセージMを送る手段
    を有する、メールシステム。
18. 前記タイムスタンプTが、現在時刻から有効期間Lを引いた時間より前である場合、受信者にメッセージMを送信しないか、若しくはタイムスタンプが古いことを受信者に知らせる手段を有する、請求項１７に記載のシステム。
19. 受信者のメーラAMLの宛先欄に送信者のアドレスが入力されたことに応答して、受信者のメーラAMLが、送信者欄に受信者のメールアドレスを設定し、メールサーバAMSにメールを送信する手段と、
    メールサーバAMSが受信者の識別子Aと送信者の識別子BとメールサーバAMSが発行したノンスNに前記メールサーバAMSのみが知る秘密鍵Kで暗号化した値{A,B,N}Kに受信者のドメイン名を付与したメールアドレス（LDアドレス）を生成し、送信者欄を前記LDアドレスに書き換える手段と、
    メールサーバAMSがユーザ拡張フィールドを作成するか、あるいは受信者がユーザ拡張フィールドを作成することに応答して、メールサーバAMSが受信者の別名を該ユーザ拡張フィールドに書き込む手段と、
    メールサーバAMSが、前記ユーザ拡張フィールドを有するメールをメールサーバBMSに送信する手段と、
    メールサーバBMSが、送信者にメールを送信する手段と、
    送信者のメーラBMLが、送信されたメールを受け取る手段と、
    送信者のメーラBMLが、前記ユーザ拡張フィールドを解釈して、前記ユーザ拡張フィールドの内容をキー、送信者フィールドの内容を値とするテーブルを作成する手段と、
    送信者のメーラBMLが、送信者フィールドを前記ユーザ拡張フィールドの内容に書き換えてユーザに提示する手段と
    を有する、メールシステム、
20. 前記メールシステムがさらに、送信者から受信者へメールの送信にあたり、
    宛先欄に入力された受信者のメールアドレスを前記テーブルを参照して対応する値を得る手段と
    前記値を宛先欄に上書きする手段と、
    前記メールをメールサーバBMSに送信する手段
    を有する請求項１９に記載のシステム。
21. 送信者から知らされた受信者へのLDアドレスを使って第３者が受信者にメールを送る手段と、
    第３者のメールサーバCMSからメールサーバAMSへメールが送信される手段と
    メールサーバAMSが、前記メールのアカウント部を復号する手段と、
    メールの送信者欄の情報と、前記復号により得られた情報を比較して、両者が一致しているか否かを判断する手段
    を有する、請求項１２〜２０に記載のシステム。
22. 前記比較の結果が一致していない場合、前記第３者が正統なメール送信者でないと判断し、前記LDアドレスを使用不可にするか、または受信者にメールを送信しないか、または受信者に警告通知を行う手段
    をさらに有する、請求項２１に記載のシステム。

Images