ドメインキー ドメインキーの概要

ドメインキー

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/02/24 23:52 UTC 版)

ナビゲーションに移動 検索に移動

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


  1. ^ John, Levine (2004年10月16日). “A large scale domain keys test”. ietf-mailsig mailing list.. オリジナルの2004年10月20日時点におけるアーカイブ。. https://web.archive.org/web/20041020010342/http://www.imc.org/ietf-mailsig/mail-archive/msg00413.html 2020年4月29日閲覧。 


「ドメインキー」の続きの解説一覧



英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「ドメインキー」の関連用語

ドメインキーのお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



ドメインキーのページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのドメインキー (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。

©2024 GRAS Group, Inc.RSS