送信者認証情報を公開していない送信サイトを認証する仕組み
【課題】 送信者認証技術は、送信してきた相手が正当な所から発信されたものかを調べる仕組みであり、迷惑メールを判別する、より精度の高い方法と言えるが、いくら受信サイトで送信者認証技術を利用する機能（プログラム）を用意したとしても、送信サイトで送信者認証情報を公開していなければ、利用出来ない技術と言える。これらの送信者認証情報を公開していないサイトにも送信者認証技術により送信者を認証し、迷惑メールの判断に活用しようとするものである。
【解決手段】 本発明は、送信者認証情報を公開していない送信サイトを認証するため、送信者認証情報をローカルなＤＮＳサーバに登録し、この情報により送信者を認証し、迷惑メールの判断に活用する。
【解決手段】 本発明は、送信者認証情報を公開していない送信サイトを認証するため、送信者認証情報をローカルなＤＮＳサーバに登録し、この情報により送信者を認証し、迷惑メールの判断に活用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信者認証技術により送信サイトを認証する仕組みに関するものである。
【背景技術】
【０００２】
近年、インターネット上で不特定多数の受信者に対し大量に送信される迷惑メールが社会的な問題となっている。
このような迷惑メールを、受信したメール本文の語彙などにより判断する方法や、受信したメールアドレスをブラックリストやホワイトリストによりチェックし判断する方式もあるが、スパム送信者との鼬ごっこの様相を呈している。
【０００３】
前記の方式よりも、一歩踏み込み、メールが正当な所から発信されたものなのかを調べる送信者認証技術は、迷惑メールを検出する有効な方法の一つと思われている。（例えば、非特許文献１参照。）
【０００４】
送信者認証技術を利用するには、メール送信側のＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）に送信者認証情報を公開すると同時に、メール受信側では公開された情報により送信相手が正しいかをチェックする機能（プログラム）が必要となる。
【０００５】
尚、送信者認証には、ＩＰベースの認証方式や暗号化ベースの認証方式などがあり、ＩＰベースの認証方式は、比較的簡易な設定などから、近年、普及の兆しは見られるものの、暗号化ベースの認証方式は、設定や運用などの複雑さなどから普及を拒んでおり、共に広く普及しているとは言えない。
【０００６】
【非特許文献１】 ＩＥＴＦ Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）４４０８“Ｓｅｎｄｅｒ Ｐｏｌｉｃｙ Ｆｒａｍｅｗｏｒｋ（ＳＰＦ）ｆｏｒ Ａｕｔｈｏｒｉｚｉｎｇ Ｕｓｅ ｏｆ Ｄｏｍａｉｎｓ ｉｎ Ｅ−Ｍａｉｌ，Ｖｅｒｓｉｏｎ １”
【発明の開示】
【発明が解決しようとする課題】
【０００７】
受信したメールアドレスをブラックリストやホワイトリストなどによりチェックし判断する方式は、送信者が正しいドメイン名やメールアドレスを使い、偽って送信して来た時には、判別出来ない欠点を持っている。
【０００８】
また、メールの内容などを判断して迷惑メールかを判断する方法は、スパム送信者が常に新しい方法を編みだしているのが現状で、常に対応を強いられ、その上、この方式では、正当なメールも誤って迷惑メールと判断されてしまうなどの問題も残されている。
【０００９】
一方、送信者認証技術のＩＰベースの認証方式は、実際にメール送信されてきたサーバアドレスと送信サイトのＤＮＳで公開されている送信メールサーバアドレスが一致するかを判断することにより認証し、暗号化の認証方式は、受信したメール内の電子署名を送信サイトのＤＮＳで公開されている公開鍵で復号化し本文であるか否かを判断し認証するが、共に、送信してきた相手が正当な相手かを調べる仕組みである。
一般的に、スパム送信者は、送信元を詐称することが多いことや常にメール本文を工夫し送信してくることなどから、リスト方式やメール本文の語彙などを判断する方式よりも、精度の高い判別法と言える。
【００１０】
このように送信者認証技術は、迷惑メールを判別する、より精度の高い方法と言えるが、この方式は、いくら受信サイトで送信者認証技術を利用する機能（プログラム）を用意したとしても、送信サイトで送信者認証情報を公開していなければ活かされないのが大きな欠点であり、普及を拒んでいる理由の一つとも言える。つまり、送信サイトで送信者認証情報を公開していなければ、受信サイトでは、そのために費やした労が報われない技術、仕組みと言える。
【００１１】
本発明は、この送信してきた相手が正当な相手かを調べる認証技術の勝れた点を活かし、送信サイトで送信者認証情報を公開していなくても、送信者認証を可能とするものであり、このことにより迷惑メールの判断に活用することを目的としている。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、送信者認証情報を公開していない送信サイトを送信者認証するために、本来、送信サイトのＤＮＳサーバで公開されるべきＩＰベースの認証方式の認証情報（送信ドメイン情報とメール送信サーバアドレス）と同じ形式の情報をローカルなＤＮＳサーバに登録し、この情報によりＩＰベースの認証方式で送信者を認証し、迷惑メールの判断に活用する。
【発明を実施するための最良の形態】
【００１３】
最良の形態を説明するにあたり図中の絵や本文中の用語について説明する。
図の中で使用されている「送信者認証情報の絵（ａａａ．ｊｐ＝・・・）」は、説明を容易にするために概念的に書いたものであり実際の構文とは違う。
また、図を使い説明の中で使用されている用語「ローカルなＤＮＳ」とは、所謂、インターネットのグローバルなアドレス空間を解決するＤＮＳとは切り離されたローカルな世界のＤＮＳを指している。
【００１４】
以下に、図面を参照し、この発明を実施するための最良の形態について説明する。
最初に、図１を使い送信者認証の動作を説明する。
【００１５】
Ａメール送信サイトの送信者ａの送信者メールソフトＭＵＡ１０により作成されたメールは、送信側のメールサーバＩＰアドレス１１１．１１１．１１１．１１１のＭＴＡ１１に転送（矢印のラベル（１）で示す）される。
【００１６】
メールサーバＭＴＡ１１は、受け取ったメール送信アドレスより受信側のメールサーバＭＴＡ１２にメールを送信（矢印のラベル（２）で示す）する。
【００１７】
メールサーバＭＴＡ１２は、メールサーバＭＴＡ１１よりメールを受け取った時、送信側のメールサーバのＩＰアドレス１１１．１１１．１１１．１１１とドメイン名ａａａ．ｊｐを記憶する。
【００１８】
メールサーバＭＴＡ１２は、送信者を認証するため、Ａメール送信サイトのＤＮＳ１３を、先に記憶したドメイン名ａａａ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（３）で示す）する。しかし、送信者認証情報が公開されていないため、認証は失敗する。
【００１９】
メールサーバＭＴＡ１２は、引き続き、ローカルなＤＮＳ１４を同じくドメイン名ａａａ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（４）で示す）する。
【００２０】
ローカルなＤＮＳ１４の送信者認証情報（ａａａ．ｊｐ ＝ １１１．１１１．１１１．１１１）が送信者のメールサーバのＩＰアドレス１１１．１１１．１１１．１１１と一致するため、送信者の認証は成功する。
認証が成功したため、メールは受信者ｘに送られる。（矢印のラベル（９）で示す）
【００２１】
一方、Ｂメール送信サイトの送信者ｂの送信者メールソフトＭＵＡ１５により作成されたメールは、送信側のメールサーバのＩＰアドレス２２２．２２２．２２２．２２２のＭＴＡ１６に転送（矢印のラベル（５）で示す）される。
【００２２】
メールサーバＭＴＡ１６は、受け取ったメール送信アドレスより受信側のメールサーバＭＴＡ１２にメールを送信（矢印のラベル（６）で示す）する。
【００２３】
メールサーバＭＴＡ１２は、メールサーバＭＴＡ１６よりメールを受け取った時、送信側のメールサーバのＩＰアドレス２２２．２２２．２２２．２２２とドメイン名ｂｂｂ．ｊｐを記憶する。
【００２４】
メールサーバＭＴＡ１２は、送信者を認証するためＢメール送信サイトのＤＮＳ１７を、先に記憶したドメイン名ｂｂｂ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（７）で示す）する。しかし、送信者認証情報が公開されていないため、認証は失敗する。
【００２５】
メールサーバＭＴＡ１２は、引き続き、ローカルなＤＮＳ１４を同じくドメイン名ｂｂｂ．ｊｐで検索し送信者認証情報を取得（矢印のラベル（８）で示す）する。
【００２６】
ローカルなＤＮＳ１４の送信者認証情報（ｂｂｂ．ｊｐ ＝ 登録無し）が登録されていないため、送信者の認証は失敗する。
【００２７】
送信者認証が失敗した場合、このメールは受信保留となり、メールなどの手段により受信者ｘ（矢印のラベル（１０）で示す）と送信者ｂ（矢印のラベル（１１）で示す）にその旨が通知される。但し、後述の自動により送信者認証情報が登録された場合（図４を使った説明）は、送信者認証が成功した時と同じ扱いとし、受信保留とはならない。
【００２８】
送信者認証が失敗した旨の通知により、メール送信者やメール受信者は、送信者認証情報の登録を要求し、ローカルなＤＮＳ１４に送信者認証情報が登録（矢印のラベル（２０）で示す）される。
【００２９】
次に、送信者認証情報の登録動作を説明する。
最初に、受信者側からの送信者認証情報登録の動作を図２の処理手順図により説明する。
メール受信者は、送信者認証が失敗した旨の通知を受け（ステップＳ１）、受信したメール内容を閲覧（ステップＳ２）し、迷惑メールであるかを判断（ステップＳ３）する。
【００３０】
メール受信者は、迷惑メールでないと判断した時は、送信者認証情報の登録を要求（ステップＳ４）する。そして、この要求を受け、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ５）する。
登録により受信保留が解除されメールは受信者へ転送される。
【００３１】
次に、送信者側からの送信者認証情報登録の動作を図３の処理手順図により説明する。
メール送信者は、送信者認証が失敗した旨の通知を受ける（ステップＳ６）。この時、受信メールには、「貴方が送信されたサイトは、送信者認証の仕組みが導入されており、送られたメールは、この認証を受けることが出来ませんでした。このため、貴方のサイトが正しい送信先であることを登録して頂く必要があります。以下のＵＲＬをアクセスし登録をお願い致します。」などの趣旨の、ご案内が含まれている。
【００３２】
メール受信者は、ＵＲＬをアクセスし送信者認証情報の登録を、申請者の情報を含め申請する。（ステップＳ７）
【００３３】
送信者認証情報の登録の申請を受け、申請者の情報の精査を経て、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ８）する。
登録により受信保留が解除されメールは受信者へ転送される。
【００３４】
次に、自動による送信者認証情報登録の動作を図４の処理手順図により説明する。
受信したメールアドレスから送信相手のＤＮＳのＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコードを検索しメールサーバのＩＰアドレスを求める（ステップＳ９）。
メールサーバのＩＰアドレスは、複数ある場合があり全て読み込む。
【００３５】
ＭＸレコードから求めたメールサーバのＩＰアドレス（複数あった場合は、全てのアドレス）とメール受信時の送信側メールサーバのＩＰアドレスを比較する（ステップＳ１０）。
【００３６】
アドレスが何れかと一致した時は、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ１１）する。
尚、この場合は、送信者認証が成功した時と同じ扱いとし、送信者認証が失敗した旨の通知の通知（図１の矢印のラベル（１０）、（１１）で示す）は出さない。
【００３７】
これまでの図２、図３、図４の方法により、送信者認証情報は、ローカルなＤＮＳに登録される。
一旦、登録された送信者認証情報は、次回、同じドメインからのメール受信時に利用され、送信者認証に活かされる。
【００３８】
尚、本発明は、以上の実施形態に限定されるものではなく、本発明の範囲内において、種々の変更実施が可能であることは言うまでもない。
【００３９】
例えば、図１の説明で送信サイトＤＮＳ１３やＤＮＳ１７を検索し送信者認証情報の存在をチェックしているが、ここでの送信者認証情報とは、ＩＰベースの認証方式と暗号化ベースの認証方式、これら両方の方式の認証情報を指しているが、選択することも可能であり、ＩＰベースの認証方式の認証情報だけの場合もあり、暗号化ベース認証方式の認証情報だけの場合もあり、両方を選択することも可能である。
送信サイトの送信者認証情報を、どの方式でチェックするかは任意であり、ＩＰベースの認証方式と暗号化ベース認証方式報の両方を選択した方が、より信頼性の高い認証結果を得ることが出来ると思われるが、それは、受信サイト側のポリシーによるものと思われる。
【００４０】
例えば、ローカルなＤＮＳに送信者認証情報を登録する方法は、図２、図３、図４の３例しか示さなかったが、他にも、検索ロボットがＷｅｂページを自動的にアクセスし、情報を収集しサーチエンジンで使用するデータベースを作る時と同じ様に、ドメイン名などからＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコード名を検索し、ドメイン名とメールサーバアドレスを自動的に収集し送信者認証情報を作り出す方法もある。
【００４１】
例えば、図１の説明では、ブラックリストやホワイトリストなどを使用していないが、送信者認証を詐称するスパム送信者もあり、これらのサイトはブラックリストなどを併用しなければならないと思われる。このため、必要に応じリスト方式の併用もあり得る。
【００４２】
例えば、ローカルなＤＮＳは、１個しか記載してないが、図２、図３、図４などの送信者認証情報の登録方法毎に分けることも可能である。このことにより、登録方法毎の認証結果に信頼性の重みを持たせることも可能であり、例えば、受信者側が登録した送信者認証情報による認証結果は、「大変高い」、送信者側が登録した送信者認証情報による認証結果は、「高い」などである。
【００４３】
例えば、ローカルなＤＮＳは、他の受信サイトと共有することも可能であり、共有することにより送信者認証情報を幅広く、より短時間で蓄積することも期待出来る。
【００４４】
例えば、ローカルなＤＮＳを送信者認証情報の登録方法により分け、受信者側からの要求により登録された送信者認証情報のローカルなＤＮＳは、複数の受信サイトで共有し、その他の方法で登録された送信者認証情報のローカルなＤＮＳは、自分のサイトのみで利用するなどの方法もある。
【００４５】
例えば、ローカルなＤＮＳを事業者が一括して運営・管理し、送信者認証情報の登録は送信サイトからの依頼により行い、これらの環境を第三者の受信サイトが利用する形態もある。
【００４６】
例えば、ローカルなＤＮＳを含め、受信サーバや受信サイトの送信者認証仕組みなどを事業者が受信サイトからの委託を受けて運営し、その結果を受信サイトが受ける利用形態もある。
【００４７】
例えば、ローカルなＤＮＳは、目的に合うのであればＤＮＳ以外のデータベースでも何ら問題はない。
【図面の簡単な説明】
【００４８】
【図１】送信者認証の動作を説明するための図である。
【図２】「受信者側からの要求により送信者認証情報を登録する動作」を説明する処理手順図である。
【図３】「送信者側からの要求により送信者認証情報の登録する動作」を説明する処理手順図である。
【図４】「自動で送信者認証情報の登録する動作」を説明する処理手順図である。
【符号の説明】
【００４９】
１０ Ａメール送信サイトのＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）
１１ Ａメール送信サイトのＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）
１２ メール受信サイトのＭＴＡ
１３ Ａメール送信サイトのＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）
１４ ローカルなＤＮＳ
１５ Ｂメール送信サイトのＭＵＡ
１６ Ｂメール送信サイトのＭＴＡ
１７ Ｂメール送信サイトのＤＮＳ
ａ Ａメール送信サイトの送信者ａ
ｂ Ｂメール送信サイトの送信者ｂ
ｘ メール受信サイトの受信者ｘ
【技術分野】
【０００１】
本発明は、送信者認証技術により送信サイトを認証する仕組みに関するものである。
【背景技術】
【０００２】
近年、インターネット上で不特定多数の受信者に対し大量に送信される迷惑メールが社会的な問題となっている。
このような迷惑メールを、受信したメール本文の語彙などにより判断する方法や、受信したメールアドレスをブラックリストやホワイトリストによりチェックし判断する方式もあるが、スパム送信者との鼬ごっこの様相を呈している。
【０００３】
前記の方式よりも、一歩踏み込み、メールが正当な所から発信されたものなのかを調べる送信者認証技術は、迷惑メールを検出する有効な方法の一つと思われている。（例えば、非特許文献１参照。）
【０００４】
送信者認証技術を利用するには、メール送信側のＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）に送信者認証情報を公開すると同時に、メール受信側では公開された情報により送信相手が正しいかをチェックする機能（プログラム）が必要となる。
【０００５】
尚、送信者認証には、ＩＰベースの認証方式や暗号化ベースの認証方式などがあり、ＩＰベースの認証方式は、比較的簡易な設定などから、近年、普及の兆しは見られるものの、暗号化ベースの認証方式は、設定や運用などの複雑さなどから普及を拒んでおり、共に広く普及しているとは言えない。
【０００６】
【非特許文献１】 ＩＥＴＦ Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）４４０８“Ｓｅｎｄｅｒ Ｐｏｌｉｃｙ Ｆｒａｍｅｗｏｒｋ（ＳＰＦ）ｆｏｒ Ａｕｔｈｏｒｉｚｉｎｇ Ｕｓｅ ｏｆ Ｄｏｍａｉｎｓ ｉｎ Ｅ−Ｍａｉｌ，Ｖｅｒｓｉｏｎ １”
【発明の開示】
【発明が解決しようとする課題】
【０００７】
受信したメールアドレスをブラックリストやホワイトリストなどによりチェックし判断する方式は、送信者が正しいドメイン名やメールアドレスを使い、偽って送信して来た時には、判別出来ない欠点を持っている。
【０００８】
また、メールの内容などを判断して迷惑メールかを判断する方法は、スパム送信者が常に新しい方法を編みだしているのが現状で、常に対応を強いられ、その上、この方式では、正当なメールも誤って迷惑メールと判断されてしまうなどの問題も残されている。
【０００９】
一方、送信者認証技術のＩＰベースの認証方式は、実際にメール送信されてきたサーバアドレスと送信サイトのＤＮＳで公開されている送信メールサーバアドレスが一致するかを判断することにより認証し、暗号化の認証方式は、受信したメール内の電子署名を送信サイトのＤＮＳで公開されている公開鍵で復号化し本文であるか否かを判断し認証するが、共に、送信してきた相手が正当な相手かを調べる仕組みである。
一般的に、スパム送信者は、送信元を詐称することが多いことや常にメール本文を工夫し送信してくることなどから、リスト方式やメール本文の語彙などを判断する方式よりも、精度の高い判別法と言える。
【００１０】
このように送信者認証技術は、迷惑メールを判別する、より精度の高い方法と言えるが、この方式は、いくら受信サイトで送信者認証技術を利用する機能（プログラム）を用意したとしても、送信サイトで送信者認証情報を公開していなければ活かされないのが大きな欠点であり、普及を拒んでいる理由の一つとも言える。つまり、送信サイトで送信者認証情報を公開していなければ、受信サイトでは、そのために費やした労が報われない技術、仕組みと言える。
【００１１】
本発明は、この送信してきた相手が正当な相手かを調べる認証技術の勝れた点を活かし、送信サイトで送信者認証情報を公開していなくても、送信者認証を可能とするものであり、このことにより迷惑メールの判断に活用することを目的としている。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、送信者認証情報を公開していない送信サイトを送信者認証するために、本来、送信サイトのＤＮＳサーバで公開されるべきＩＰベースの認証方式の認証情報（送信ドメイン情報とメール送信サーバアドレス）と同じ形式の情報をローカルなＤＮＳサーバに登録し、この情報によりＩＰベースの認証方式で送信者を認証し、迷惑メールの判断に活用する。
【発明を実施するための最良の形態】
【００１３】
最良の形態を説明するにあたり図中の絵や本文中の用語について説明する。
図の中で使用されている「送信者認証情報の絵（ａａａ．ｊｐ＝・・・）」は、説明を容易にするために概念的に書いたものであり実際の構文とは違う。
また、図を使い説明の中で使用されている用語「ローカルなＤＮＳ」とは、所謂、インターネットのグローバルなアドレス空間を解決するＤＮＳとは切り離されたローカルな世界のＤＮＳを指している。
【００１４】
以下に、図面を参照し、この発明を実施するための最良の形態について説明する。
最初に、図１を使い送信者認証の動作を説明する。
【００１５】
Ａメール送信サイトの送信者ａの送信者メールソフトＭＵＡ１０により作成されたメールは、送信側のメールサーバＩＰアドレス１１１．１１１．１１１．１１１のＭＴＡ１１に転送（矢印のラベル（１）で示す）される。
【００１６】
メールサーバＭＴＡ１１は、受け取ったメール送信アドレスより受信側のメールサーバＭＴＡ１２にメールを送信（矢印のラベル（２）で示す）する。
【００１７】
メールサーバＭＴＡ１２は、メールサーバＭＴＡ１１よりメールを受け取った時、送信側のメールサーバのＩＰアドレス１１１．１１１．１１１．１１１とドメイン名ａａａ．ｊｐを記憶する。
【００１８】
メールサーバＭＴＡ１２は、送信者を認証するため、Ａメール送信サイトのＤＮＳ１３を、先に記憶したドメイン名ａａａ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（３）で示す）する。しかし、送信者認証情報が公開されていないため、認証は失敗する。
【００１９】
メールサーバＭＴＡ１２は、引き続き、ローカルなＤＮＳ１４を同じくドメイン名ａａａ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（４）で示す）する。
【００２０】
ローカルなＤＮＳ１４の送信者認証情報（ａａａ．ｊｐ ＝ １１１．１１１．１１１．１１１）が送信者のメールサーバのＩＰアドレス１１１．１１１．１１１．１１１と一致するため、送信者の認証は成功する。
認証が成功したため、メールは受信者ｘに送られる。（矢印のラベル（９）で示す）
【００２１】
一方、Ｂメール送信サイトの送信者ｂの送信者メールソフトＭＵＡ１５により作成されたメールは、送信側のメールサーバのＩＰアドレス２２２．２２２．２２２．２２２のＭＴＡ１６に転送（矢印のラベル（５）で示す）される。
【００２２】
メールサーバＭＴＡ１６は、受け取ったメール送信アドレスより受信側のメールサーバＭＴＡ１２にメールを送信（矢印のラベル（６）で示す）する。
【００２３】
メールサーバＭＴＡ１２は、メールサーバＭＴＡ１６よりメールを受け取った時、送信側のメールサーバのＩＰアドレス２２２．２２２．２２２．２２２とドメイン名ｂｂｂ．ｊｐを記憶する。
【００２４】
メールサーバＭＴＡ１２は、送信者を認証するためＢメール送信サイトのＤＮＳ１７を、先に記憶したドメイン名ｂｂｂ．ｊｐで検索し、送信者認証情報を取得（矢印のラベル（７）で示す）する。しかし、送信者認証情報が公開されていないため、認証は失敗する。
【００２５】
メールサーバＭＴＡ１２は、引き続き、ローカルなＤＮＳ１４を同じくドメイン名ｂｂｂ．ｊｐで検索し送信者認証情報を取得（矢印のラベル（８）で示す）する。
【００２６】
ローカルなＤＮＳ１４の送信者認証情報（ｂｂｂ．ｊｐ ＝ 登録無し）が登録されていないため、送信者の認証は失敗する。
【００２７】
送信者認証が失敗した場合、このメールは受信保留となり、メールなどの手段により受信者ｘ（矢印のラベル（１０）で示す）と送信者ｂ（矢印のラベル（１１）で示す）にその旨が通知される。但し、後述の自動により送信者認証情報が登録された場合（図４を使った説明）は、送信者認証が成功した時と同じ扱いとし、受信保留とはならない。
【００２８】
送信者認証が失敗した旨の通知により、メール送信者やメール受信者は、送信者認証情報の登録を要求し、ローカルなＤＮＳ１４に送信者認証情報が登録（矢印のラベル（２０）で示す）される。
【００２９】
次に、送信者認証情報の登録動作を説明する。
最初に、受信者側からの送信者認証情報登録の動作を図２の処理手順図により説明する。
メール受信者は、送信者認証が失敗した旨の通知を受け（ステップＳ１）、受信したメール内容を閲覧（ステップＳ２）し、迷惑メールであるかを判断（ステップＳ３）する。
【００３０】
メール受信者は、迷惑メールでないと判断した時は、送信者認証情報の登録を要求（ステップＳ４）する。そして、この要求を受け、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ５）する。
登録により受信保留が解除されメールは受信者へ転送される。
【００３１】
次に、送信者側からの送信者認証情報登録の動作を図３の処理手順図により説明する。
メール送信者は、送信者認証が失敗した旨の通知を受ける（ステップＳ６）。この時、受信メールには、「貴方が送信されたサイトは、送信者認証の仕組みが導入されており、送られたメールは、この認証を受けることが出来ませんでした。このため、貴方のサイトが正しい送信先であることを登録して頂く必要があります。以下のＵＲＬをアクセスし登録をお願い致します。」などの趣旨の、ご案内が含まれている。
【００３２】
メール受信者は、ＵＲＬをアクセスし送信者認証情報の登録を、申請者の情報を含め申請する。（ステップＳ７）
【００３３】
送信者認証情報の登録の申請を受け、申請者の情報の精査を経て、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ８）する。
登録により受信保留が解除されメールは受信者へ転送される。
【００３４】
次に、自動による送信者認証情報登録の動作を図４の処理手順図により説明する。
受信したメールアドレスから送信相手のＤＮＳのＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコードを検索しメールサーバのＩＰアドレスを求める（ステップＳ９）。
メールサーバのＩＰアドレスは、複数ある場合があり全て読み込む。
【００３５】
ＭＸレコードから求めたメールサーバのＩＰアドレス（複数あった場合は、全てのアドレス）とメール受信時の送信側メールサーバのＩＰアドレスを比較する（ステップＳ１０）。
【００３６】
アドレスが何れかと一致した時は、先に記憶しておいた、このメールの送信側メールサーバのＩＰアドレスとドメイン情報により、ローカルなＤＮＳ１４に送信者認証情報を登録（ステップＳ１１）する。
尚、この場合は、送信者認証が成功した時と同じ扱いとし、送信者認証が失敗した旨の通知の通知（図１の矢印のラベル（１０）、（１１）で示す）は出さない。
【００３７】
これまでの図２、図３、図４の方法により、送信者認証情報は、ローカルなＤＮＳに登録される。
一旦、登録された送信者認証情報は、次回、同じドメインからのメール受信時に利用され、送信者認証に活かされる。
【００３８】
尚、本発明は、以上の実施形態に限定されるものではなく、本発明の範囲内において、種々の変更実施が可能であることは言うまでもない。
【００３９】
例えば、図１の説明で送信サイトＤＮＳ１３やＤＮＳ１７を検索し送信者認証情報の存在をチェックしているが、ここでの送信者認証情報とは、ＩＰベースの認証方式と暗号化ベースの認証方式、これら両方の方式の認証情報を指しているが、選択することも可能であり、ＩＰベースの認証方式の認証情報だけの場合もあり、暗号化ベース認証方式の認証情報だけの場合もあり、両方を選択することも可能である。
送信サイトの送信者認証情報を、どの方式でチェックするかは任意であり、ＩＰベースの認証方式と暗号化ベース認証方式報の両方を選択した方が、より信頼性の高い認証結果を得ることが出来ると思われるが、それは、受信サイト側のポリシーによるものと思われる。
【００４０】
例えば、ローカルなＤＮＳに送信者認証情報を登録する方法は、図２、図３、図４の３例しか示さなかったが、他にも、検索ロボットがＷｅｂページを自動的にアクセスし、情報を収集しサーチエンジンで使用するデータベースを作る時と同じ様に、ドメイン名などからＭＸ（Ｍａｉｌ ｅＸｃｈａｎｇｅ）レコード名を検索し、ドメイン名とメールサーバアドレスを自動的に収集し送信者認証情報を作り出す方法もある。
【００４１】
例えば、図１の説明では、ブラックリストやホワイトリストなどを使用していないが、送信者認証を詐称するスパム送信者もあり、これらのサイトはブラックリストなどを併用しなければならないと思われる。このため、必要に応じリスト方式の併用もあり得る。
【００４２】
例えば、ローカルなＤＮＳは、１個しか記載してないが、図２、図３、図４などの送信者認証情報の登録方法毎に分けることも可能である。このことにより、登録方法毎の認証結果に信頼性の重みを持たせることも可能であり、例えば、受信者側が登録した送信者認証情報による認証結果は、「大変高い」、送信者側が登録した送信者認証情報による認証結果は、「高い」などである。
【００４３】
例えば、ローカルなＤＮＳは、他の受信サイトと共有することも可能であり、共有することにより送信者認証情報を幅広く、より短時間で蓄積することも期待出来る。
【００４４】
例えば、ローカルなＤＮＳを送信者認証情報の登録方法により分け、受信者側からの要求により登録された送信者認証情報のローカルなＤＮＳは、複数の受信サイトで共有し、その他の方法で登録された送信者認証情報のローカルなＤＮＳは、自分のサイトのみで利用するなどの方法もある。
【００４５】
例えば、ローカルなＤＮＳを事業者が一括して運営・管理し、送信者認証情報の登録は送信サイトからの依頼により行い、これらの環境を第三者の受信サイトが利用する形態もある。
【００４６】
例えば、ローカルなＤＮＳを含め、受信サーバや受信サイトの送信者認証仕組みなどを事業者が受信サイトからの委託を受けて運営し、その結果を受信サイトが受ける利用形態もある。
【００４７】
例えば、ローカルなＤＮＳは、目的に合うのであればＤＮＳ以外のデータベースでも何ら問題はない。
【図面の簡単な説明】
【００４８】
【図１】送信者認証の動作を説明するための図である。
【図２】「受信者側からの要求により送信者認証情報を登録する動作」を説明する処理手順図である。
【図３】「送信者側からの要求により送信者認証情報の登録する動作」を説明する処理手順図である。
【図４】「自動で送信者認証情報の登録する動作」を説明する処理手順図である。
【符号の説明】
【００４９】
１０ Ａメール送信サイトのＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）
１１ Ａメール送信サイトのＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）
１２ メール受信サイトのＭＴＡ
１３ Ａメール送信サイトのＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）
１４ ローカルなＤＮＳ
１５ Ｂメール送信サイトのＭＵＡ
１６ Ｂメール送信サイトのＭＴＡ
１７ Ｂメール送信サイトのＤＮＳ
ａ Ａメール送信サイトの送信者ａ
ｂ Ｂメール送信サイトの送信者ｂ
ｘ メール受信サイトの受信者ｘ
【特許請求の範囲】
【請求項１】
送信者認証情報を公開していない送信サイトを送信者認証するために、本来、送信サイトのＤＮＳサーバで公開されるべきＩＰベースの認証方式の認証情報と同じ形式の情報をローカルなＤＮＳサーバに登録し、この情報によりＩＰベースの認証方式で送信者を認証する仕組み。
【請求項１】
送信者認証情報を公開していない送信サイトを送信者認証するために、本来、送信サイトのＤＮＳサーバで公開されるべきＩＰベースの認証方式の認証情報と同じ形式の情報をローカルなＤＮＳサーバに登録し、この情報によりＩＰベースの認証方式で送信者を認証する仕組み。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−２５９１７６（Ｐ２００９−２５９１７６Ａ）
【公開日】平成２１年１１月５日（２００９．１１．５）
【国際特許分類】
【出願番号】特願２００８−１３０１２５（Ｐ２００８−１３０１２５）
【出願日】平成２０年４月１５日（２００８．４．１５）
【出願人】（５０８１４６９６１）
【Ｆターム（参考）】
【公開日】平成２１年１１月５日（２００９．１１．５）
【国際特許分類】
【出願日】平成２０年４月１５日（２００８．４．１５）
【出願人】（５０８１４６９６１）
【Ｆターム（参考）】
[ Back to top ]