われわれが受け取るジャンク・メールの量は大変なものだ。これを抑制してくれるいくつかのソリューションが開発途上にある。今のところほとんどの人は，自分の電子メールをフィルタする助けとして，次の3つの形のソリューションのいずれか（またはそれらの組み合わせ）を使っているだろう。メールの送信者が，（1）自分が認めた送信者か，（2）受け取り拒否対象の送信者か，（3）受け取り拒否対象のメール・サーバーか――に従って判断する方法だ。ほかにもさらにもう3つのソリューションが市場に登場しつつある。「Sender Policy Framework（SPF）」と「Caller ID for E-Mail」と「DomainKeys」である。

送信者のIPアドレスをDNSで確認する「SPF」
　Meng Weng Wong氏とMark Lentczner氏は1年以上前にSPFの開発に取り組み始めたが，既に7500人以上のドメイン運用者がそのソリューションを導入した。世界最大のISP（インターネット・サービス・プロバイダ）の1つであるAOLも，SPFに注目してテストしている。

　SPFは電子メールの送信者のIPアドレスを確認するために，DNSへ問い合わせる。通常のDNSはドメインに関する問い合わせに対し，受信用（インバウンド）のメール・サーバーのMXレコードを公開する。しかし，所定のドメインに関する送信用（アウトバウンド）のメール・サーバーのリストを公開するレコード・タイプはない。これを改善し，SPFは送信用のメール・サーバー（のアドレス）を公開するため，DNS内で特別にフォーマットされたTXTレコードを使う。

　SPFが有効になっているメール・システムが，あるメッセージを受け取るとき，そのメール・システムは送信者のドメインのDNSサーバーに対して問い合わせ，認証されている送信用のメール・サーバーのアドレスのリストを取得して，それらのアドレスをメッセージのSMTPメール・ヘッダーにあるIPアドレスと比較できる。もし，IPアドレスがマッチすれば，そのメール・システムはそのメッセージはジャンク・メールじゃないと推測できる。もし，アドレスが一致しないなら，そのメール・システムがどう設定されるかによるが，様々な対応を採れる。SPFの実装方法も含めさらに詳しい情報はWebサイトにある（該当サイト）。

XMLファイルを使う「Caller ID for E-Mail」
　Microsoftは最近，SPFに似たCaller ID for E-Mailという仕様を発表した。Caller IDもDNS TXTレコードを使って動作する。しかし，Caller IDはXMLで書かれたTXTレコードを使う。Caller IDはSPFと同じく，あるメッセージを送ってきたのが，あるドメインの正式なメール・サーバーであることを確認するために，SMTPメール・ヘッダー内のIPアドレスをDNSサーバーが公開している外向きのメール・サーバーのIPアドレスと比較してチェックする。Caller IDとSPFの違いは，メール・ヘッダーの処理方法と，送信用のメール・サーバーをDNSが公開する方法である。Microsoftが提案しているCaller ID for Emailシステムについては，同社のWebサイトでさらに詳しく調べられる（該当サイト）。

電子署名を利用する「DomainKeys」
　3番目のシステム，DomainKeysはYahoo!が開発したものだ。サーバー・レベルでメッセージに暗号を使った署名をすることで機能する。Pretty Good Privacy（PGP）のような，公開鍵と秘密鍵を使うツールのことはよくご存知だろう。データは，秘密鍵を使って暗号化されるかまたは署名され，そのデータは公開鍵を使って復号されるか，または署名を確認される。DomainKeysも同じ方法を使うが，サーバー・レベルで動作するところがポイントだ。送信側のメール・サーバーはそれが送るメッセージすべてに秘密鍵を使って署名する。DNSレコードを使って送信側サーバーの公開鍵を公開するようにする。相手のサーバーが署名付きのメッセージを受け取った場合，そのサーバーはDNSクエリーを使って送信側の公開鍵を取得して，その鍵でメッセージに付けられた署名を確認する。