電子署名を使うDomainKeysの設定方法：送信ドメイン認証技術解説（2/4 ページ）

DomainKeysはメールの転送に強い

　Sender IDなどIPアドレスベースの認証方式は送信元のIPアドレスを基に認証処理をするため、メールが転送された場合に認証が失敗する。DomainKeysはヘッダに追加した電子署名とその電子署名の元になったメールのヘッダおよび本文などが変化しない限り（つまり、電子署名が壊れない限り）、転送した先でも認証処理が実施できる。これがDomainKeysが転送に強いといわれる理由である。

　しかし、配送途中のMTAなどにおいて、署名の対象になったメールのデータに何らかの変化が加わると電子署名が壊れてしまい認証に失敗する。このような電子署名の破壊を防ぐため、送信側では電子署名する前にデータを正規化する。例えば、メール本文の空改行などをすべて取り除いたうえで電子署名を行う。

DomainKeysはメーリングリストが苦手

　メーリングリストの多くは「Subject:」ヘッダに通し番号を追加する。また、本文の末尾にフッタなどを追加する場合もある。DomainKeysの署名を持つメールをそのようなメーリングリストに投稿するとメーリングリストの加入者へメールを配送するときに電子署名が破壊される。

図2 DomainKeysとメーリングリストの関係（クリックで拡大）
　（1）A.COMのメールサーバからB.COMのメーリングリストサーバへ投稿
　（2）B.COMのメーリングリストサーバがメンバへ投稿を配送。このとき、「Subject:」ヘッダに通し番号が付与される
　（3）メンバが所属するC.COMは、投稿の送信元ドメインであるA.COMから公開鍵を取得する
　（4）電子署名の基になったデータがB.COMのメーリングリストサーバで変更されているため、電子署名の照合ができず認証に失敗する

　これを回避するには、メーリングリストエンジンでヘッダや本文を変更した後に、メーリングリストを運営しているドメインを送信ドメインとする「Sender:」ヘッダを追加し、あらためて電子署名を作成し、新しい「DomainKey-Signature:」ヘッダを追加する必要がある。また、「Subject:」ヘッダのみを編集するメーリングリストも多いので、電子署名を実施する際の対象から「Subject:」を外しておくという方法も考えられる。

　なお、メーリングリストのほとんどはメールを再配送するときにエンベロープの送信者を自ドメインのものに置き換えるため、IPアドレスベースの認証方式（特にClassic SPF）が利用できる。

送信サーバと受信サーバにおける注意点

　DomainKeysを導入する場合、送信側では電子署名に利用する鍵を作成し、公開鍵をDNS上に公開する。また、実際に署名するメールフィルタを配置する。

　一方、受信側では電子署名をチェックするフィルタが必要になる。上述したように、DomainKeysではメールのデータが配送中に書き換わらない限り認証が可能である。従って、Sender IDのように必ずしも自ドメインの最も外側に配置したMTAで実施する必要はない。

　しかし、現実の企業のメールシステムではウイルス対策フィルタやポリシーフィルタなどが配置されており、外部からのメールが実際にユーザーのメールボックスに届くまで何段ものメールサーバ（MTA）を経由することが普通になっているため、DomainKeysの電子署名処理と認証処理のどちらも内部ネットワークのなるべく外側に近い場所で実施することが望ましいと考えられる。また、署名のときにもh=タグを利用して署名の対象にしたヘッダを表示しておくようにしよう。

ほかのメール暗号化方式との関係

　DomainKeysは、S/MIMEやPGPなど既存の電子署名や暗号化技術の利用を妨げないようにデザインしてある。つまり、DomainKeysを導入してもS/MIMEを使ったソリューションを並行して運用可能だ。

　実際にS/MIMEを利用した電子署名でフィッシィング詐欺に対応するというソリューションも提案されている。この技術はDomainKeysと比較されることが多いが、それぞれに長所や短所がある。それ故、送信ドメイン認証とそれらの技術とは競合するものではなく、共存するものだと考えられている。