ドメインキー 欠点

ウィキペディア

ドメインキー

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

欠点

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

配送途中の内容改変

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

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

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

プロトコルの負荷

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