ループ防止案(1)「エラーメールは転送元のスプールに保存する方法」の長所は、エラーメールが転送元のスプールに確実に残ることである。短所は、エラーメールを転送先で読めないという意味で、これまでの利便性を損なうことである。
ループ防止案(2)「エラーメールの場合は、SMTP MAIL FROMを上書きせず、“<>”のままで転送する方法」の長所は、転送先でエラーが起こらない限り、これまでの利便性を維持できることである。短所は、エラーが発生すると、エラーメールは結果的に消去され、送信者も受信者もエラーの発生に気づけないことである。
転送先でのエラーのうち、“user unknown”となる場合は、そもそも転送の設定が間違っている。これは転送の設定を直せばよく、本質的な問題ではない。起こりうる深刻なエラーは、転送先のスプールが溢れている場合である。防止案(2)を採用する場合、転送先でスプールが溢れると、それ以降のメールはすべて無くなってしまう。
何かを得れば、何かを失い場合が多い。本稿の提案は、エラーメールよりもSPF認証の方が重要であるという価値観に基づき、SPF認証を取り、エラーメールの一部を犠牲にする。
防止案(1)と防止案(2)は、ユーザごとに選択可能である。
エラーメールに対してもSPF認証を実行しなければならない。実行しないなら、迷惑メール配送業者は、エラーメールで迷惑メールを送りつけてくるだろう。
エラーメールのSMTP MAIL FROMは“<>”であり、ドメイン名が指定されていない。そこで、エラーメールに対しては、SMTP HELO/EHLOに指定されたドメイン名に対してSMTP認証を実行する。
逆に言えば、すべての送信サーバは、SMTP HELO/EHLOに(ホスト名ではなく)正しいドメイン名を指定しなければならない。
エラーメールが送信者に戻ることを維持しながら、SPFと転送の相性問題を解決する方法に「SRS」がある。 SRSを導入する際は、転送元だけが対応すればよい。ただ、転送が多重になった際の動作が複雑であることに注意されたい。
本稿で述べた転送問題の解決案と「SPFを普及させるため提案」により、SPFは本格的に普及するのではないかと期待できる。以下にそのシナリオをまとめる。
普及期前半
普及期後半
普及期前半で、送信元のSPF RRが“~all”と宣言されているとし、そのドメインから送信されたメールが転送されることを考えよう。転送先が「自分自身でエラーメールを返すタイプのサーバ」で「普及のための提案」を採用しているとする。転送元が本稿の提案を採用していない場合は、SPF認証の結果がsoftfailとなる。スプールが溢れている場合は、送信者へエラーメールを返す。“user unknown”の場合は、エラーメールを発生させない。そのため送信者も受信者も、エラーの発生に気づかない。しかしながら、“user unknown”となるのは、明らかに転送設定のミスである。転送を設定した場合は、直後に動作を確かめ、ミスが起こらないようにするべきである。
転送元が本稿の提案を採用すると、転送先のSPF認証の結果がpassとなる。そこで、“user unknown”のエラーが発生した場合、エラーメールが転送元に返されるようになる。また、スプールが溢れた場合も、エラーメールが転送元に返される。この場合の動作は、「考察」の章で述べた通りである。
《PREV》 |