コンテンツにスキップ

ドメインキー

出典: フリー百科事典『ウィキペディア（Wikipedia）』

ドメインキー（DomainKeys）はインターネット・メールの認証システムであり、メール発信者のドメインと通信内容の完全性の正当性を確認できる。

DomainKeysとアイデンティファイド・インターネット・メール（IIM: Identified Internet Mail）の仕様は、ドメインキー・アイデンティファイド・メール（DKIM: DomainKeys Identified Mail）と呼ばれる拡張プロトコルに統合された。

DKIMは、2007年5月に発行され、2011年9月に改定されている。DomainKeysの草案は、2007年5月に"歴史的"（historical）状態として発行された。

概説

[編集]

DomainKeysとは、電子メールの認証技術である。その他の方法と異なり、DomainKeysは署名するメール転送エージェント（MTA: Mail Transfer Agent）から検証するMTAまで、ほぼエンド・ツー・エンドの完全性を提供する。多くの場合、署名するMTAが発信者に代わり、また検証するMTAが受信者に代わり機能する。DomainKeysは、Historic（歴史的） RFC 4870に定められている。このRFC 4870はStandards Track（標準化過程） RFC 4871やRFC 6376「DomainKeys Identified Mail (DKIM) Signatures」によって廃止された。

DomainKeysは、RFC 5321で定められたSMTPのエンベロープ部ではなく、RFC 5322で定められた通信内容（つまり送信されたメールデータ、メールヘッダ、メール本文）に対して機能するため、Simple Mail Transfer Protocol（SMTP）による配送経路には依存しない。

DomainKeysは迷惑メールの発信を直接防止する技術ではない。偽装や改竄を防ぐ効果は、メールの発信者と受信者の双方に利益があり、いくつかの電子メールクライアントはDomainKeysに対応している。

2004年以降、Yahooは外部へ送る全てのメールにDomainKeysの署名をしており、また外部から届く全てのメールを検証している。2005年現在、Yahooが受信する3億通以上/日のメールがDomainKeysにより検証されている、とYahoo!は報告している。

Yahoo!が実施する1ヶ月前には、Gmailサービスの利用者から送信されるメールに署名するために、GoogleもDomainKeysを採用している。[1]

動作方法

[編集]

DomainKeysは、メールの内容に対するデジタル署名データを含む「DomainKey-Signature」というメールヘッダを追加する。標準の認証機構は、メッセージ・ダイジェストとしてSHA-1、公開鍵暗号方式としてRSAを用い、Base64を用いて暗号化されたハッシュデータをエンコードする

受信側のSMTPサーバは、メールの送信元ドメイン名、文字列「_domainkey」、そしてセレクタをメールヘッダから取り出す。送信元ドメインのDNSサーバに問い合わせて、そのドメインの公開鍵を取得する。次に受信者は、「DomainKey-Signature:」ヘッダ中のデータを、公開鍵を使用して復号しメッセージ・ダイジェスト（と一致するはずの値）を得る。別途、受信メール本文のメッセージ・ダイジェストを計算する。もし2つのハッシュ値が一致したら、対象のメールが、そのメールの発信元と言われているドメインで作られたこと、また配送中に改竄されていないということが、暗号学的に立証される。

開発

[編集]

DomainKeysはYahoo!のMark Delanyによって設計された。その他多数の人々が意見を寄せ、プログラムを試作した。その中には、qmailコミュニティーのRuss Nelson、sendmailのEric Allman、そしてASRGのJohn R. Levineが含まれる。

DomainKeysは米国特許アメリカ合衆国特許第 6,986,049号として保護され、Yahoo!に割り当てられた。Yahoo!は二種類のライセンス（1. 従来から有りオープンソースやフリーソフトウェアのプログラムに適するように設計された、無料、非独占的、再許諾可能な企業指向の特許ライセンス、2. DKIM IETFワーキング・グループの目的のためのGPL 2.0）の下でDomainKeysを発表した。

長所

[編集]

DomainKeysにはメール受信者にとって主に3つの長所がある。

  • メールの発信元ドメインを特定し、ドメインを基にしたブラックリストとホワイトリストをより効果的に機能させる。これはフィッシング攻撃をより容易に発見することも期待できる。
  • エンド・ユーザの電子メールクライアント（MUA: Mail User Agent）かISPのメール転送エージェントにより、詐称されたメールを破棄できる。
  • 不正なドメインの所有者をより容易に追跡できる。

メール送信者にとっても、外部へ送り出すメールを認証することによる利点がある。

  • DomainKeyに対応したドメインを詐称するメールは、受信側で自動的に捨てられる。そのため、ドメイン所有者は、偽装メールの受信者からの苦情に対応する労力を削減できる。
  • その結果、ドメイン所有者は、そのドメインの正当なアカウントを所持していて、それを悪用している者に、労力を集中できる。

迷惑メールフィルタとの併用

[編集]

DomainKeysは認証技術のため、DomainKeys自身は迷惑メールを取り除かない。しかしながら、DomainKeysが普及することにより、迷惑メールの常套手段である発信者アドレスを詐称することを防止できる。迷惑メールの正しい発信元ドメインを表示させることができれば、その他のフィルタ技術はより効果を上げることができる。特に発信元ドメインは、迷惑メールを識別するためのレピュテーション（評判、格付け）のデータに有効である。

DomainKeysは迷惑メールを識別するのだけではなく、フィルタの不要なメールを識別し易くできる。メールの受信システムに信頼できるホワイトリストがあれば、リストに記載された既知のドメインから発信された署名メールはフィルタを通さずに受け取ることができる。また残りのメールに対してはより積極的にフィルタをかけることができる。

DomainKeysはフィッシング詐欺に対抗する技術としても有効である。何度もフィッシングの標的にされるドメインでは、そのドメインから送信するメールが真正な物であることを表明するために署名を使える。メール受信者は、それらのドメインから届いたメールに署名がなければ、それは詐称された可能性が高い物であるという目安として扱える。ホワイトリストに載せるドメインをDomainKeysとの連携に値する精度で決定する最良の方法は、未解決のままである。DomainKeysの後継であるDKIMでは、送信者に全ての送信メールに自己識別のための署名をさせるセンダー・サイニング・ポリシー（SSP: Sender Signing Policy）と呼ばれる選択機能を持つと考えられるが、SSPの有効性についてはまだ試されていないままである。

互換性

[編集]

DomainKeysは、RFC 5322のメールヘッダとDNSレコードの、任意で設定できる箇所を使い実装されているため、既存の電子メール基盤に下位互換性がある。Domainkeysに対応していない既存の電子メールシステムに対して、DomainKeysは影響を与えない。

DomainKeysは電子メールシステムへのその他の拡張提案、特にSPF、S/MIMEメール標準、およびDNSSECと両立できるように設計されていた。DomainKeysはOpenPGP標準とも互換性がある。

欠点

[編集]

DomainKeysやDKIM は、発信者と受信者の情報を持つエンベロープ部を署名の対象に含まない。どの暗号ソリューションでも、メッセージの不正な反復（Message Replay Abuse）は懸念事項である。これは大きなドメインからの不正の度合いについて現在の制限を迂回する技術である。メッセージ毎に異なる公開鍵の使用、DNSに対する公開鍵の検索要求の追跡、そして大規模なメーリングリストへの投稿に起因する過大な検索要求や悪人による悪質な問い合わせを取り除くことで、反復は推測できる。またこの問題に関する別の対策との比較は、送信ドメイン認証を参照。

配送途中の内容改変

[編集]

DomainKeysの問題の1つは、もし配送途中でメーリングリストサーバなどの転送機能が通信内容を大幅に改変すると、署名が無効になり、そのドメインが全メールが署名されているものと指定されていれば、そのメールは拒否されるということである（その解決策は、既知の転送サーバから届くメールをホワイトリストに載せるか、または転送サーバにおいて署名を検証し、メールを改変し、そしてメールにSender:ヘッダを付加した上で再署名することである）。しかしながら、多くのドメインは、そこから発信するメールの一部だけが署名されると設定されている。そのため署名がないことや検証の失敗によって、必ずしもメールが破棄されるとは限らない（その解決策は発信するメール全てに署名することである）。もし配送中の改変がDomainKey-Signature:ヘッダより前のメールヘッダの追加や修正に伴うだけならば、その署名は有効なままである。またDomainKeysの仕組みは、署名を無効にせず、メールヘッダとメール本文へ限られた改変のできる仕組みがある。

この制限はDomainKeysとSPFの組合せで対処できると提案されている。なぜならば、SPFはメールデータの改変に影響されず、また通常はメーリングリストはメーリングリスト自身のSMTPエラーアドレス「Return-Path」を使用するためである。要するにSPFはDomainKeysが苦手とする場所で役立ち、またその逆の場合も同じである。

メールの内容に加筆あるいは改変を施すメーリングリストは、DomainKeysの署名を無効にする。そのような状況ならば、メーリングリストシステムが改変後の内容に署名し直すことで、通信文に責任を負うべきである、とYahoo!は提案した。

プロトコルの負荷

[編集]

DomainKeysは、メールサーバを経由し送られる通信内容ごとにデジタル署名を必要とする。それはメール配送のためには不要な計算負荷をもたらす。

脚注

[編集]
[脚注の使い方]
  1. ^ John, Levine (16 October 2004). "A large scale domain keys test". ietf-mailsig (Mailing list). 2004年10月20日時点のオリジナルよりアーカイブ。2020年4月29日閲覧。

関連項目

[編集]

外部リンク

[編集]
「https://ja.wikipedia.org/w/index.php?title=ドメインキー&oldid=97769814」から取得