メールアドレスは、アットマークを挟んで、ユーザ名とドメイン名に分けられます。前述のようにSMTP AUTHを用いれば、ユーザ名の部分が認証できるようになります。加えて、ドメイン名の部分まで認証できれば、メールアドレスを詐称することができなくなります。
ドメインの部分を認証する技術は「ドメイン認証」と呼ばれ、IPアドレスに基づく方法と電子署名に基づく方法に大別できます。ここでは、前者の例としてSPF（Sender Policy Framwork）、後者の例としてDKIM（DomainKeys Identified Mail）を取り上げます。どちらもDNSのセキュリティに依存します。
SPFは、送信サーバを宣言する仕組みです（図6）。SPFの送信側は、ドメインに対する送信サーバのIPアドレスをDNSに登録します。メール配送の際、受信側では、まずSMTPコネクションの送信側のIPアドレス(a)を取得します。また、SMTP MAIL FROMに指定されたメールアドレスからドメイン部分を取り出します。そのドメインに対しDNSを検索して、宣言された送信サーバのIPアドレス(b)を得ます。(a)が(b)に合致していれば、そのドメインの正式な送信サーバから送られてきたことが分かります。
●図6 SPFの仕組み
example.jpは、DNSを使い、送信サーバのIPアドレスは192.0.2.1と宣言。example.jpからのメールを受け取ったメールサーバは、DNSを索いて得られるIPアドレスとSMTPコネクションのIPアドレスとを比較する。
▼ DKIM（DomainKeys Identified Mail）
DKIMは、ドメインレベルでメールに署名し、その署名を検証する仕組みです（図7）。DKIMの送信側は、まず公開鍵と秘密鍵の組を作成します。公開鍵をDNSで公開し、秘密鍵は送信サーバにインストールします。メールを送る際は、この送信サーバが秘密鍵を用いてメールに署名します。受信側では、署名の部分からドメイン名を特定し、それに対する公開鍵をDNSから得ます。そして、その公開鍵を使って署名を検証します。
●図7 DKIMの仕組み
example.jpは、送信サーバに秘密鍵を設定し、DNSで公開鍵を公開する。送信サーバは、メールを送信する前に秘密鍵を使い署名を作成する。example.jpからのメールを受け取ったメールサーバは、DNSを索いて得られる公開鍵で署名を検証する。
SPFにしろ、DKIMにしろ、受信側でドメインの認証により詐称と判断した場合、将来的には受信を拒否するか、受信してから捨てるようにします。しかしながら、普及の初期段階である現時点では、設定間違いや実装の誤りがあると思われるため、認証の結果をヘッダに残してメールボックスへ入れます。実際にメールを振り分ける作業は、メールリーダに任せるわけです。また、たとえば、認証に成功したメールは通常のメールボックスへ、失敗したメールはゴミ箱へ格納するといった実装も考えられます。
SPFもDKIMも一長一短があり、それぞれの欠点を補うために組み合わせて使うことが提案されていますが、ここでは詳細には踏み込みません。
| 《PREV》 |