IIJ
技術研究所
山本和彦
2006年1月
1. 要旨
2. SPFの普及に関する問題点
3. 予備知識
4. 提案
5. 考察
1. 要旨
本稿では、SPFを普及させるために以下のように提案する。
- “~”（softfail）の意味を「受け取らなければならないが、エラーメールは返さなくてもよい」と定義する。
- DNSでSPFリソースレコード（以下「RR」）を宣言する際は、allのプレフィックスとして （“-”の利用がためらわれる場合）“~”を選択する。“?”は使用すべきではない。
- user unknownなどの理由によりエラーメールを返す際に、送信アドレスに対するSPFの検査がsoftfailまたはfailである場合は、エラーメールを返さない。
2. SPFの普及に関する問題点
SPFは、メールアドレスのドメイン部分を認証するドメイン認証の一種である。その安全性は、DNSのそれに依存する。
SPF では、あるドメインに対する送信サーバのIPアドレスを宣言する。受信側は、SMTP MAIL FROMに指定された送信アドレスからドメインを切り出し、DNSを検索して、そのドメインに対する送信サーバのIPアドレスを得る。これを、SMTPコネクションの相手側のIPアドレスと比較することで、ドメイン部分の正当性を検証する。
このように、SPFの仕組みは、送信側の宣言と受信側での検証からなり、サイト（ドメイン）では独立して導入できる。おおざっぱな言い方ではあるが、SPFでは、送信サーバを宣言するドメインが増えなければ、受信側で検証できるメールの比率も増加しない。SPFの普及のためには、まず送信サーバを宣言するドメインを増やしていく必要があるが、それには以下の問題点があると考えられる。
- 送信サーバを宣言しても、普及率が低い時期はメリットが少ない。逆に、宣言の設定を誤るとメールが受け取ってもらえなくなるリスクを伴う。これらを比較し、宣言しない方を選択してしまいがちである。
- 送信サーバを宣言するとしても、allのプレフィックスとして“?”を選択する。これは、allに合致した場合、宣言してないことと同じであるため、受信側のメリットを損ねている。
そこで本稿では、送信サーバを宣言すると、自分のドメインに届く不要なエラーメールが少なくなる方法を提示する。現在、エラーメールのほとんどはドメインを詐称されることによって発生しており、これらの不要なエラーメールは受信サーバに大きな負荷をかけている。この負荷が軽減されることは、大きなメリットとなるはずである。このメリットにより、送信サーバを宣言するドメインの数が増加することを期待する。
3. 予備知識
本稿での提案を理解しやすくするために、まずハーベスティングについて説明する。
ハーベスティングとは、メールアドレスを収集する行為を言う。まず、Webなどに公開されているメールアドレスを収集する方法が挙げられる。また、あるドメインの受信サーバにメールを送るふりをして、実際にユーザが存在するか調べる方法もある。そのメールアドレスのリストは、乱数／総当たり的に生成されたもの、人名などの辞書を使うもの、そしてWebから収集したものなどが考えられる。
受信サーバに問い合わせるハーベスティングは、以下のような手順が一般的である。まず、SMTP MAIL FROMに詐称したメールアドレスを指定する。次に、SMTP RCPT TOに対しメールアドレスのリストから1つを選んで指定する。メールサーバから「要求が正常に終了した」という応答（250）が返れば、そのメールアドレスが有効であると判断する。この後、可能な限りSMTP RCPT TOを繰り返し、リストを検証していく。
ハーベスティングを防ぐために、受信サーバのいくつかはSMTP RCPT TOで指定されたメールアドレスのユーザ名が有効であろうとなかろうと、常に250を返しメールを受け取るよう設定されている。この種の受信サーバは、エラーメールを自分自身で生成し送信する。ハーベスティングに対するエラーメールは、多くの場合SMTP MAIL FROMに詐称したメールアドレスが指定されているため、返すこと自体が詐称されたドメインにとって迷惑である。事実、ハーベスティングによって引き起こされる大量のエラーメールは、受信サーバに大きな負荷をかけるDoSとなっている。
また多量の不要なメールは、ウイルスによっても引き起こされる。ウイルスが送るメールは、送信者が詐称されていることが多い。このメールの受信者が存在しない場合は、エラーメールが詐称された送信者へ返る。また、受信側でウイルスの検知を通知するタイプのアンチウイルス製品を利用している場合、検知メールが詐称された送信者へ送られる。
4. 提案
SPFをエラーメールの低減に役立てるために、以下のように提案する。
まず、allのプレフィックスである“~”（softfail）であるが、仕様では「neutralとfailの中間として扱う」と書かれているだけであり、意味が曖昧である。そこで、softfailの意味を「受け取らなければならない（受信は拒否してはならない）」とする。また、ハーベスティング対策を施した受信サーバでは、「エラーメールは返さなくてもよい」と定義することを提案する。
ハーベスティング対策を施した受信サーバの動作を以下のように変更するよう提案する。受信側では、まずSPFの検証結果を保存しておく。次に、user unknownなどの理由でエラーメールを返す際に、保存しておいたSPFの検証結果を参照する。これがsoftfailあるいはfailであれば、送信アドレスは詐称されているのだからエラーメールを返さないようにする。これにより、送信サーバを宣言していれば、ドメインを送信アドレスに悪用されても、それに対するエラーメールは届かなくなる。
SPF RRを使い送信サーバを宣言する際は、allのプレフィックスとして“~”か“-”を利用する。最初は“~”が妥当であろう。“?”と宣言しているドメインは、なるべく早く“~”に変更する。
5. 考察
エラーメールのほとんどはハーベスティングやウイルスによって引き起こされており、ほとんどが無意味である。これを低減させることには抵抗が少ないはずである。
エラーメールが減るというメリットがあれば、SPF RRを宣言するサイトが増えるだろう。受信側でSPFを活用しエラーメールを返さないサイトが増えれば、ますますエラーメールは減っていく。このような好循環から、送信側も受信側もSPFの導入が進むことを期待したい。
SPF は、SMTPレベルの転送と相性が悪い。メールが転送されて届いた場合、SPFの検証はドメインが詐称されているという結果となる。しかしながら、本稿の提案した“~”が宣言されていれば、転送されたメール自体は受信される。転送先でuser unknownとなった場合は、本来返るべきエラーメールが返らないが、そもそもその転送の設定は間違っていると考えられ、設定自体を直すべきである。