SPF/Sende IDでメール防衛

概要

昨今，phishing詐欺(フィッシング詐欺)などで，勝手に会社名やメールアドレスが，身元を詐称に使われる被害が出ています．
こうした詐欺は，もちろん加害者が悪いのですが，事前に防ぐための手段を取ることで，未然に被害を防ぐ手法を紹介したいと思います．
今回紹介するSPF(Sender Policy Framework)/Sender IDはメールアドレスの悪用を防ぐための技術で，既存のシステムの設定を変えるだけでよいので，簡単に導入することができます．基本的に新たなソフトウェアなどを入れる必要はありません．

なりすましとは

現在のメールの仕組みでは，メールを一目見ただけでは，そのメールに書かれた送信者が，実際の送信者であるかどうかを確認することは困難になっています．
携帯電話では，迷惑メール対策としてなりすまし規制(キャリア各社で呼び方が違います)ができますが，これはいわゆるホワイトリストと呼ばれる手法で，メールの送信元として予め想定されているホスト以外からのメールは受け取らないようになってます．
これは携帯電話キャリアが数少ないために可能な技術であり，不特定多数が動作するインターネットのメールの世界では難しいといえます．
逆の発想として，メールの送信元として好ましくないホストからのメールを受け取らなくするブラックリストもありますが，問題を多く抱えているため，根本的な解決法にはなっていません．

SPF/Sender IDとは？

SPFはMeng Weng Wong氏が開発していた技術で，似たような技術であるCaller IDを開発中だったMicrosoftと，お互いの技術を統合することで生まれたのがSender IDです．
DNSの設定を変更することで，メールの送信元ホストを認証するようになっています．
具体的には，DNSのTXTレコードを活用し，該当するホスト名のメールアドレスから送られるメールの，送信元ホストのホワイトリストを提供するようになっています．例えば，送信者がhogehoge@bitcoffee.comのメールを，SPF/Sender IDで検証してみます．
まず，送信者のメールアドレスのホスト名，bitcoffee.comのTXTレコードを参照します．
太字で示したところを実際に入力します．[CRLF]は改行のことで，リターンキーを押すことを示しています．

sakuma@JUSHI /home/sakuma%  dig TXT bitcoffee.com[CRLF]

; <<>> DiG 9.3.1 <<>> TXT bitcoffee.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bitcoffee.com.                 IN      TXT

;; ANSWER SECTION:
bitcoffee.com.          10      IN      TXT     "v=spf1 a mx ip4:69.93
.197.163 mx:mail.bitcoffee.com ip4:69.93.197.12 mx:mail2.bitcoffee.com
 ~all"

;; Query time: 30 msec
;; SERVER: 202.224.32.1#53(202.224.32.1)
;; WHEN: Wed Feb 22 21:38:39 2006
;; MSG SIZE  rcvd: 120

この場合，hogehoge@bitcoffee.comのメールの送信元として，69.93.197.163か，69.93.197.12で全てである，という意味になります．
つまり，これ以外のホストから送られてきたメールは，詐称してある可能性があるという意味です．もちろん，正式なメールであっても，後述するいくつかの問題点により，異なるホストから送られてくる可能性もあります．

SPFとSender IDの違い

DNSを用いてホワイトリストを提供するという，ほとんど同じ技術ですが，送信元の情報をどこで判断するかが異なります．
SPFでは，SMTPサーバ間の通信で用いられる，MAIL FromのEnvelopeが用いられます．しかし，この情報は多くのMUA(Mail User Agent)では表示されないので，ユーザが判断するには難しいといえます．
この点を改善するため，Sender IDでは，From，Sender，Resent-From，Resent-Senderなどが用いられます．

DNSに設定する

DNSにTXTレコードを追加するだけなので，DNSの管理権があればレンタルサーバでも設定できます．
しかし，設定を間違えると，正しいはずのメールが詐称メールと間違われかねないので注意が必要です．
また，SPFの書き方は複雑な設定ができるようになっているため，ツールなどを使って生成した方が安心です．

導入状況

SPF/SenderIDなどの技術は，広く使われないとあまり意味がありません．
規格を推奨しているMicrosoftは導入に積極的で，例えば同社のHotmailのサービスには導入されてます．
また，GoogleのGMailでも導入されています．
携帯電話キャリアでは，KDDI(au，Tu-Ka)，DoCoMo，Willcomなどが導入しています．

問題点

メーリングリストの配信やメール転送などを行った場合，異なるメールサーバから送信されることになるため，正常に送られない場合が想定されます．
自社のサーバではなく，プロバイダのメールサーバを使ってるユーザの場合，ローミングサービスを使うなどして，異なるメールサーバを用いて送信する際に，やはり同様の問題がおきます．
しかし，これは今後，受信側で何らかの対策が行われていくと思われます．