Michael R. Brumm wrote:
http://www.michaelbrumm.com/spf-forwarding.html
Thanks.
Let me know if there are any mistakes.
Maybe you could add another disadvantage in the third column:
Bounces can go directly to the (forged) sender bypassing the
spammer (pretending to be a forwarder).
Maybe we could test this problem with MAIL FROM:<@a:user(_at_)b>
to some backup MX and addresses which are known to not exist:
- If the bounce goes to @a with RCPT TO:<user(_at_)b>, and @a relays
it to user(_at_)b, then there's no problem.
- If @a rejects the bounce, claiming that it doesn't relay to @b,
then that would be inconclusive: A real forwarder would of
cause relay bounces, and a spammer pretending to be a forwarder
is free to do whatever he wants.
- If the bounce goes directly to user(_at_)b, then this would break
the original idea of SPF.
Or you add another required modification: All MXs must support
reverse source route bouncing in the same way as it was in the
times of UUCP, but of course using the "modern" RfC 821 syntax.
Bye, Frank