IIJ
技術研究所
山本和彦
2006年3月
1. SPFと転送の相性問題
2. 転送とエラーメール
3. 解決案への要求事項
4. SMTP MAIL FROMの上書きとループの発生
5. ループの防止案（1）
6. ループの防止案（2）
7. 考察
8. 補足
9. 補足2
10. SPF 普及のシナリオ
11. 転送に関するさらなる考察
1. SPFと転送の相性問題
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アドレス）。
2. 転送とエラーメール
これからの議論のための予備知識として、転送とエラーメールの関係について説明する。
転送先が「エラーコードを返すタイプのサーバ」である場合、エラーメールは転送元が生成する。そのエラーメールは送信者に返る（下図の赤色）。
転送先が「自分自身でエラーメールを返すタイプのサーバ」である場合、転送先はメールをいったん受け取りエラーメールを生成する。そのエラーメールは送信者に返る（下図の赤色）。
3. 解決案への要求事項
SPFと転送の相性問題を解決するために、「SMTP MAIL FROMのSUBMITTERパラメータ」が提案されている。
これは、SMTPの書式を変更していため、転送元だけでなく転送先も対応する必要がある。すなわち、転送元と転送先が足並みをそろえて対応しなければならないので、普及しにくいだろう。普及の実現性を考慮すれば、転送元だけで対応できるようにSMTPの書式を変えてはならない。
また、後述のように解決策によっては、エラーメールがループを引き起こす。ループしたエラーメールは、メールのホップ数の上限まで配送が繰り返され、資源を無駄遣いする。そのため、このようなループは防止できなくてはならない。
以下に解決案への要求事項をまとめる。
- 転送元だけの対応で済むようにSMTPの書式は変更しない
- ループの発生を防止できる
4. SMTP MAIL FROMの上書きとループの発生
「転送元だけの対応で済むようにSMTPの書式は変更しない」という制約の下では、誰でも「転送元でSMTP MAIL FROMを上書きする」という方法を思いつく。そこで、転送元でSMTP MAIL FROMを上書きし、転送元のメールアドレスを指定することを考える。下の図で明らかなように、example.netは 192.0.2.2 に合致する（橙色のドメイン名に橙色のIPアドレス）。そこで、この方法を用いれば、転送先でのSPF認証の結果は「本物」となる。
残念ながらこの方法は、このままでは、エラーメールのループを引き起こす。
転送先でなんらかの原因により、エラーが発生したとしよう。転送先が「自分自身でエラーメールを返すタイプのサーバ」である場合、エラーメールは転送元に戻る。このエラーメールは、SMTP MAIL FROMが上書きされて、転送先に転送される。再転送されたエラーメールは転送されたメールと区別できないので、ループが発生する。このループは、転送元か転送先が定めるメールのホップ数の最大に達するまで解消されない。SPFの仕様書の9.3章でも、考察がここで止まっている。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、このループは発生しない。
5. ループの防止案（1）
エラーメールは、SMTP MAIL FROMが“<>”であることから、通常のメールと区別が可能である。ループの防止案（1）として、「エラーメールは転送元のスプールに保存する方法」を提案する。ループが起こらないのは自明である。
エラーメールの中から、転送先から戻ってきたものだけを選別し、転送元のスプールに保存できれば理想的である。しかし実際は、転送先から戻ってきたと判断することは困難である。そのため、すべてのエラーメールを転送元のスプールに保存する方法が現実的である。
たとえば下の図で、bobが bob@example.net を名乗り、どこかへメールを出し、それに対してエラーメールが発生したとしよう。下の図では桃色となる。これは、転送先からのエラーメールではないので、転送するのが理想的である。転送先でエラーが生じなければ、bobは bob@example.com でそのエラーメールを読める。残念ながら、この解決案では、これを実現できない。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、転送元はメールをスプールに保存する。
6. ループの防止案（2）
もう一つのループの防止案として、「エラーメールの場合は、SMTP MAIL FROMを上書きせず、“<>”のままで転送する方法」を提案する。
転送先からのエラーメールを受け取った転送元は、再び転送先に転送する。SMTPでは、エラーメールへのエラーメールは発生しない。そこで、転送先でエラーメールのループが止まる。ただし、エラーメールは消去される。
転送先以外からのエラーメール（下図の桃色）も、転送先に転送される。転送先でエラーが生じなければ、エラーメールは転送先に保存される。転送先でエラーが生じれば、このエラーメールは消去される。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、転送元はエラーメールを送信者へ戻す。
7. 考察
ループ防止案（1）「エラーメールは転送元のスプールに保存する方法」の長所は、エラーメールが転送元のスプールに確実に残ることである。短所は、エラーメールを転送先で読めないという意味で、これまでの利便性を損なうことである。
ループ防止案（2）「エラーメールの場合は、SMTP MAIL FROMを上書きせず、“<>”のままで転送する方法」の長所は、転送先でエラーが起こらない限り、これまでの利便性を維持できることである。短所は、エラーが発生すると、エラーメールは結果的に消去され、送信者も受信者もエラーの発生に気づけないことである。
転送先でのエラーのうち、“user unknown”となる場合は、そもそも転送の設定が間違っている。これは転送の設定を直せばよく、本質的な問題ではない。起こりうる深刻なエラーは、転送先のスプールが溢れている場合である。防止案（2）を採用する場合、転送先でスプールが溢れると、それ以降のメールはすべて無くなってしまう。
何かを得れば、何かを失い場合が多い。本稿の提案は、エラーメールよりもSPF認証の方が重要であるという価値観に基づき、SPF認証を取り、エラーメールの一部を犠牲にする。
防止案（1）と防止案（2）は、ユーザごとに選択可能である。
8. 補足
エラーメールに対してもSPF認証を実行しなければならない。実行しないなら、迷惑メール配送業者は、エラーメールで迷惑メールを送りつけてくるだろう。
エラーメールのSMTP MAIL FROMは“<>”であり、ドメイン名が指定されていない。そこで、エラーメールに対しては、SMTP HELO/EHLOに指定されたドメイン名に対してSMTP認証を実行する。
逆に言えば、すべての送信サーバは、SMTP HELO/EHLOに（ホスト名ではなく）正しいドメイン名を指定しなければならない。
9. 補足2
エラーメールが送信者に戻ることを維持しながら、SPFと転送の相性問題を解決する方法に「SRS」がある。 SRSを導入する際は、転送元だけが対応すればよい。ただ、転送が多重になった際の動作が複雑であることに注意されたい。
10. SPF普及のシナリオ
本稿で述べた転送問題の解決案と「SPFを普及させるため提案」により、SPFは本格的に普及するのではないかと期待できる。以下にそのシナリオをまとめる。
普及期前半
- 受信側ではSPF認証の結果がなんであれ、必ずメールを受け取る。認証結果はヘッダに残す。
- 送信側では、SPF RRの宣言で、“all”の限定子として“~”（softfail）を指定する。
- 受信側が「自分自身でエラーメールを返すタイプのサーバ」であり、“user unknown”になった場合、SPF認証の結果がsoftfailあるいはfailならエラーメールを返さない。これにより、SPF RRを宣言すると受け取るエラーメールが減るというメリットが生まれる。
- 転送元では、本稿の提案を採用する。それにより、SPFと転送の相性問題を解決できる。転送元が本稿の提案を採用していないため転送でSPF認証が「詐称」となることは、受信メールのヘッダを見れば判断できる。
普及期後半
- 受信側では、SPF認証の結果により受信するかを決定する。failなら受信拒否。softfailなら受信する（“user unknown”ならエラーメールは返さない）。
- 送信側では、SPF RRの宣言で、“all”の限定子として “-”（fail）を指定する。
11. 転送に関するさらなる考察
普及期前半で、送信元のSPF RRが“~all”と宣言されているとし、そのドメインから送信されたメールが転送されることを考えよう。転送先が「自分自身でエラーメールを返すタイプのサーバ」で「普及のための提案」を採用しているとする。転送元が本稿の提案を採用していない場合は、SPF認証の結果がsoftfailとなる。スプールが溢れている場合は、送信者へエラーメールを返す。“user unknown”の場合は、エラーメールを発生させない。そのため送信者も受信者も、エラーの発生に気づかない。しかしながら、“user unknown”となるのは、明らかに転送設定のミスである。転送を設定した場合は、直後に動作を確かめ、ミスが起こらないようにするべきである。
転送元が本稿の提案を採用すると、転送先のSPF認証の結果がpassとなる。そこで、“user unknown”のエラーが発生した場合、エラーメールが転送元に返されるようになる。また、スプールが溢れた場合も、エラーメールが転送元に返される。この場合の動作は、「考察」の章で述べた通りである。