IIJ
技術研究所
山本和彦
2006年3月
1. SPFと転送の相性問題
2. 転送とエラーメール
3. 解決案への要求事項
4. SMTP MAIL FROMの上書きとループの発生
5. ループの防止案（1）
6. ループの防止案（2）
7. 考察
8. 補足
9. 補足2
10. SPF 普及のシナリオ
11. 転送に関するさらなる考察
SPFはIPアドレスに依存した技術であるため、転送によりドメイン名とIPアドレスの対応関係が変わると、SPFの認証結果は「詐称」となる（SPFリソースレコード（RR）が “~all”であればsoftfail、“-all”であればfailとなる）。
下の図では、alice@example.jp が bob@example.net にメールを送り、bob@example.net は bob@example.com に転送されている。example.jpの送信サーバは 192.0.2.1、example.netの送信サーバは 192.0.2.2 と宣言されているとしよう。
example.netでのSPF認証の結果は「本物」（pass）となる。なぜなら、SMTP MAIL FROMにはexample.jpと指定されており、SMTPコネクションの相手のIPアドレスが 192.0.2.1 であるため、合致するからである（緑色のドメイン名に緑色のIPアドレス）。
これに対し、example.comでのSPF認証の結果は「詐称」となる。その原因は、転送ではSMTP MAIL FROMの値は変わらずexample.jpのままであるのに対し、SMTPコネクションの相手のIPアドレスが 192.0.2.2 となるからである（緑色のドメイン名に橙色のIPアドレス）。
これからの議論のための予備知識として、転送とエラーメールの関係について説明する。
転送先が「エラーコードを返すタイプのサーバ」である場合、エラーメールは転送元が生成する。そのエラーメールは送信者に返る（下図の赤色）。
転送先が「自分自身でエラーメールを返すタイプのサーバ」である場合、転送先はメールをいったん受け取りエラーメールを生成する。そのエラーメールは送信者に返る（下図の赤色）。
SPFと転送の相性問題を解決するために、「SMTP MAIL FROMのSUBMITTERパラメータ」が提案されている。
これは、SMTPの書式を変更していため、転送元だけでなく転送先も対応する必要がある。すなわち、転送元と転送先が足並みをそろえて対応しなければならないので、普及しにくいだろう。普及の実現性を考慮すれば、転送元だけで対応できるようにSMTPの書式を変えてはならない。
また、後述のように解決策によっては、エラーメールがループを引き起こす。ループしたエラーメールは、メールのホップ数の上限まで配送が繰り返され、資源を無駄遣いする。そのため、このようなループは防止できなくてはならない。
以下に解決案への要求事項をまとめる。