送信ドメイン認証

送信ドメイン認証技術

送信ドメイン認証とは，送信者のアドレスが正規なものであることを証明する技術である．メールアドレスのドメインを見て，それがが正規のサーバから発信されているか否かを検証するものである．これは送信者を偽って送りつけられる，いわゆる「なりすまし」を検出，排除するために開発された技術である．フィッシング詐欺や迷惑メールのほとんどは「なりすまし」によって送られている．現在のメール送信技術では，送信元とされる From アドレスを簡単に詐称することができる．

銀行や公益事業，電子商取引サービスといった業務用のメールを利用者へ頻繁に送るような事業者にとって，送信ドメイン認証技術の利用は有効である．利用者をフィッシング詐欺（利用者が信頼する事業者のドメインとメールの内容をまねて偽のサイトへ誘導し，クレジットカードの番号やパスワードなどの情報を取得すること）から保護できる．

送信ドメイン認証の技術は，大きく次の 2種類に分けられる．

IP アドレスの検証
送信元 IPアドレスを根拠に正規のサーバから送られたかどうかを検証する技術であり，SPF (Sender Policy Framework) や Sender ID がある．
SPF や Sender ID では，受信側のメールサーバが送信側の DNSサーバから差出人のメールアドレスにあるドメイン名でメールを送信することを許可したメールサーバの IPアドレスを入手する．この情報を SPFレコードという．受信側のメールサーバは，メールを転送してきた送信側のメールサーバの IPアドレスと SPFレコードを照合して，一致していればなりすましではない，一致していなければなりすましの可能性が高い，と判断する．SPF と Sender ID の違いは，SPF が差出人のメールアドレスとして「From：」で指定されたものを参照するのに対して，Sender IDはヘッダーに記述されたメールアドレスを参照するところにある．
ディジタル署名の利用
送られたメールの中にディジタル署名を挿入し，その正当性を検証する技術であり，DKIM (DomainKeys Identified Mail) がある．
DKIM は Cisco社が提唱していた IIM（Identified Internet Mail）と Yahoo!社が提唱していた DomainKeys を統合したものである．ただし，既存の DomainKeys 利用者の DKIM への移行を考慮して，お互いを干渉させることなく同時に使用できる設計となっている． DKIM は2007年5月に IETFにおいて RFC 4871 として承認された．

送信ドメイン認証を行うには，送信側と受信側のそれぞれが同じ送信ドメイン認証技術に対応する必要がある．

DKIM (DomainKeys Identified Mail)

概要
スパムメール，フィッシングメールなどの迷惑メールへの対策として Yahoo!社，Cisco Systems社，Sendmail社，PGP社の4社により共同開発された送信ドメイン認証技術である．
DKIM では，送信側でディジタル署名を施し，受信側でディジタル署名の検証を行う．送信元を偽装したスパムメールやフィッシングメールは，正しい署名を添付することができないため，受信者の手元に届く前に偽者と見破られて破棄することができる．
DKIM とは，メール送信者のドメインと，送信されたメールの一貫性（たとえば送信途中で変更されていないということ）の両方を認証するための仕組みをプロバイダに提供することによって，正当なメールと偽造されたメールを判断することができる技術である．
DKIM で取られているアプローチは，以前からある電子メール署名技術（例えば S/MIME や OpenPGP とは以下の点で異なる．
- メッセージの署名はメールヘッダーのフィールドとして書かれるため，受信者も MUA (Mail User Agent) もメッセージ本文に署名関係の内容が書かれた場合も，それと混同することがない．
- 信頼性のある認証局により発行された公開鍵と秘密鍵のペアに依存する必要がない．
- 公開鍵の配布や抹消に関して，新しいプロトコルやサービスの適用が不要である．
- 署名の認証に失敗しても，メッセージの受信拒否は強制されない．
- 暗号化の仕組みは含まれない．
公開鍵の提供
DKIMでは，送信側のドメインを管理する DNSサーバを使用して，署名に利用する公開鍵を公開する．公開鍵は， FQDN（Fully Qualified Domain Name：完全修飾ドメイン名）に対する TXTレコードとして DNS に登録する．鍵の長さは，512ビットから 2048ビットをサポートしている．

DKIM では広範な普及を目指すため，鍵作成のコストを抑え，より多くのサイトにて利用できるように考慮している．DKIM でのディジタル署名では，第三者認証局が発行した電子証明書を利用するのではなく，OpenSSLなどのツールを使って各ドメインの担当者らが，自身が管理するドメインの鍵を自身で作成する．
公開鍵の取得
公開鍵を DNSサーバから取得する際に，どのドメインレコードを参考にするかは，DKIM-Signature に書かれているドメイン名により決定される．しかし，DKIM-Signature に記載されるドメイン名は，ヘッダーの From に書かれるメールアドレスとは独立しているため，両者が食い違う可能性がある．DKIM では食い違った場合を「Third Party Signature」，一緒だった場合を「First Party Signature」と呼んで区別する．

First Party Signatureで照合に成功した場合は，疑わしい部分がないものとして扱う．一方，Third Party Signatureの場合は，ヘッダーの Fromアドレスに記載されているドメインの「Author Domain Signing Practices（ADSP）」レコードを DNSに問い合わせる．ADSP には Third Party Signatureの場合にどう取り扱うかうべきかという情報が記録されている．例えば，他のドメインによって署名されるような運用をしているのであれば，Fromアドレスのドメインの管理者はADSPにThird Party Signatureを受け入れるように記載を行なう必要があり，逆に他のドメインによって署名されるような運用をしていないのであれば，Third Party Signatureのメールを破棄するように ADSPに記載する必要がある．

DKIM はこのように，受信側のメールサーバにメールを転送したメールサーバと，ディジタル署名を行ったメールサーバが同じでなくても認証が可能である．例えば，メール本文や件名などを変更せずにそのまま送り出す自動転送で届いたメールでも対応できる．(SPF と Sender ID では，自動転送メールだと IPアドレスが変わるため，認証できない．)
DKIM の基本的動作
- 鍵の生成
  ドメイン所有者（主に企業やプロバイダのメールシステム管理者）は，メールに署名するための公開鍵/秘密鍵のペアを生成する．公開鍵は DNS サーバで公開され，秘密鍵は DKIM が実装された送信メールサーバで署名時に利用される．
- 送信サーバ
  送信側では，次の手順により電子メールのヘッダおよび本文を元にディジタル署名を作成し，DKIM-Signature ヘッダとして追加する．DKIM-Signature ヘッダの書式は，“タグ＝値”の組を“;”で区切って列挙したものである．
  1. 署名対象のメールか確認する．
  2. 署名対象のヘッダを決定し，タグに列挙する．
  3. メールの本文の正規化処理 (メールを配送する際のメールのデータの変更に対応するため) を実施する．
  4. ヘッダ，正規化したメール，追加する DKIM-Signature ヘッダの署名データを除いた部分を結合したデータに対してハッシュ値を作成する．
  5. ハッシュ値に対して秘密鍵を用いてディジタル署名を作成し，DKIM-Signature ヘッダに追加したのち，DKIM-Signature 自体をヘッダに追加する．
- 受信サーバ
  受信側では，メッセージに付与された DKIM-Signature ヘッダを取り出し，次の手順で署名の検証を行う．
  1. DKIM-Signature ヘッダのタグの値から公開鍵を取得する FQDN（Fully Qualified Domain Name：完全修飾ドメイン名）を作成する．
  2. 作成した FQDN から公開鍵を取得する．
  3. タグに記述してあるヘッダとメール本文，およびディジタル署名データ以外の DKIM-Signature ヘッダの値を併せてハッシュ値を作成する
  4. 受信したディジタル署名と作成したハッシュ値を使って公開鍵で署名を検証する．
  5. 署名の検証結果に基づいてメールを配送する．送信ドメインが認証されれば受信箱に，認証されなければ破棄またはフラグをつけるといった予め決められたポリシーを適用する．