「転送元だけの対応で済むようにSMTPの書式は変更しない」という制約の下では、誰でも「転送元でSMTP MAIL FROMを上書きする」という方法を思いつく。そこで、転送元でSMTP MAIL FROMを上書きし、転送元のメールアドレスを指定することを考える。下の図で明らかなように、example.netは 192.0.2.2 に合致する（橙色のドメイン名に橙色のIPアドレス）。そこで、この方法を用いれば、転送先でのSPF認証の結果は「本物」となる。
残念ながらこの方法は、このままでは、エラーメールのループを引き起こす。
転送先でなんらかの原因により、エラーが発生したとしよう。転送先が「自分自身でエラーメールを返すタイプのサーバ」である場合、エラーメールは転送元に戻る。このエラーメールは、SMTP MAIL FROMが上書きされて、転送先に転送される。再転送されたエラーメールは転送されたメールと区別できないので、ループが発生する。このループは、転送元か転送先が定めるメールのホップ数の最大に達するまで解消されない。SPFの仕様書の9.3章でも、考察がここで止まっている。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、このループは発生しない。
エラーメールは、SMTP MAIL FROMが“<>”であることから、通常のメールと区別が可能である。ループの防止案（1）として、「エラーメールは転送元のスプールに保存する方法」を提案する。ループが起こらないのは自明である。
エラーメールの中から、転送先から戻ってきたものだけを選別し、転送元のスプールに保存できれば理想的である。しかし実際は、転送先から戻ってきたと判断することは困難である。そのため、すべてのエラーメールを転送元のスプールに保存する方法が現実的である。
たとえば下の図で、bobが bob@example.net を名乗り、どこかへメールを出し、それに対してエラーメールが発生したとしよう。下の図では桃色となる。これは、転送先からのエラーメールではないので、転送するのが理想的である。転送先でエラーが生じなければ、bobは bob@example.com でそのエラーメールを読める。残念ながら、この解決案では、これを実現できない。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、転送元はメールをスプールに保存する。
もう一つのループの防止案として、「エラーメールの場合は、SMTP MAIL FROMを上書きせず、“<>”のままで転送する方法」を提案する。
転送先からのエラーメールを受け取った転送元は、再び転送先に転送する。SMTPでは、エラーメールへのエラーメールは発生しない。そこで、転送先でエラーメールのループが止まる。ただし、エラーメールは消去される。
転送先以外からのエラーメール（下図の桃色）も、転送先に転送される。転送先でエラーが生じなければ、エラーメールは転送先に保存される。転送先でエラーが生じれば、このエラーメールは消去される。
なお、転送先が「エラーコードを返すタイプのサーバ」である場合は、転送元はエラーメールを送信者へ戻す。
| 《PREV》 |