本稿での提案を理解しやすくするために、まずハーベスティングについて説明する。
ハーベスティングとは、メールアドレスを収集する行為を言う。まず、Webなどに公開されているメールアドレスを収集する方法が挙げられる。また、あるドメインの受信サーバにメールを送るふりをして、実際にユーザが存在するか調べる方法もある。そのメールアドレスのリストは、乱数／総当たり的に生成されたもの、人名などの辞書を使うもの、そしてWebから収集したものなどが考えられる。
受信サーバに問い合わせるハーベスティングは、以下のような手順が一般的である。まず、SMTP MAIL FROMに詐称したメールアドレスを指定する。次に、SMTP RCPT TOに対しメールアドレスのリストから1つを選んで指定する。メールサーバから「要求が正常に終了した」という応答（250）が返れば、そのメールアドレスが有効であると判断する。この後、可能な限りSMTP RCPT TOを繰り返し、リストを検証していく。
ハーベスティングを防ぐために、受信サーバのいくつかはSMTP RCPT TOで指定されたメールアドレスのユーザ名が有効であろうとなかろうと、常に250を返しメールを受け取るよう設定されている。この種の受信サーバは、エラーメールを自分自身で生成し送信する。ハーベスティングに対するエラーメールは、多くの場合SMTP MAIL FROMに詐称したメールアドレスが指定されているため、返すこと自体が詐称されたドメインにとって迷惑である。事実、ハーベスティングによって引き起こされる大量のエラーメールは、受信サーバに大きな負荷をかけるDoSとなっている。
また多量の不要なメールは、ウイルスによっても引き起こされる。ウイルスが送るメールは、送信者が詐称されていることが多い。このメールの受信者が存在しない場合は、エラーメールが詐称された送信者へ返る。また、受信側でウイルスの検知を通知するタイプのアンチウイルス製品を利用している場合、検知メールが詐称された送信者へ送られる。
SPFをエラーメールの低減に役立てるために、以下のように提案する。
まず、allのプレフィックスである“~”（softfail）であるが、仕様では「neutralとfailの中間として扱う」と書かれているだけであり、意味が曖昧である。そこで、softfailの意味を「受け取らなければならない（受信は拒否してはならない）」とする。また、ハーベスティング対策を施した受信サーバでは、「エラーメールは返さなくてもよい」と定義することを提案する。
ハーベスティング対策を施した受信サーバの動作を以下のように変更するよう提案する。受信側では、まずSPFの検証結果を保存しておく。次に、user unknownなどの理由でエラーメールを返す際に、保存しておいたSPFの検証結果を参照する。これがsoftfailあるいはfailであれば、送信アドレスは詐称されているのだからエラーメールを返さないようにする。これにより、送信サーバを宣言していれば、ドメインを送信アドレスに悪用されても、それに対するエラーメールは届かなくなる。
SPF RRを使い送信サーバを宣言する際は、allのプレフィックスとして“~”か“-”を利用する。最初は“~”が妥当であろう。“?”と宣言しているドメインは、なるべく早く“~”に変更する。
エラーメールのほとんどはハーベスティングやウイルスによって引き起こされており、ほとんどが無意味である。これを低減させることには抵抗が少ないはずである。
エラーメールが減るというメリットがあれば、SPF RRを宣言するサイトが増えるだろう。受信側でSPFを活用しエラーメールを返さないサイトが増えれば、ますますエラーメールは減っていく。このような好循環から、送信側も受信側もSPFの導入が進むことを期待したい。
SPFは、SMTPレベルの転送と相性が悪い。メールが転送されて届いた場合、SPFの検証はドメインが詐称されているという結果となる。しかしながら、本稿の提案した“~”が宣言されていれば、転送されたメール自体は受信される。転送先でuser unknownとなった場合は、本来返るべきエラーメールが返らないが、そもそもその転送の設定は間違っていると考えられ、設定自体を直すべきである。
| 《PREV》 |