■ SPFを普及させるための提案（前半） 　　　

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に合致した場合、宣言してないことと同じであるため、受信側のメリットを損ねている。

そこで本稿では、送信サーバを宣言すると、自分のドメインに届く不要なエラーメールが少なくなる方法を提示する。現在、エラーメールのほとんどはドメインを詐称されることによって発生しており、これらの不要なエラーメールは受信サーバに大きな負荷をかけている。この負荷が軽減されることは、大きなメリットとなるはずである。このメリットにより、送信サーバを宣言するドメインの数が増加することを期待する。

　

《NEXT》