Stuart D. Gathman writes:
But all of the "forwarding problem" sob stories in spf-discuss I can
recall have been about attempting to check SPF for mail from your own
MX servers - an obvious misconfiguration.
I can't comment on what stories you might have seen, but you
completely misunderstood what I said. The forwarding problem has
nothing to do with SPF checking of one's own MXs, and exactly none of
the SPF forwarding issue discussion I've seen over the last year has
involved such internal relaying. (Anybody inept enough to apply SPF
checks during their internal relaying should have someone else
handling their email.)
Trying one more time to explain what the problem actually is, we begin
with JaneDoe(_at_)aol(_dot_)com sending mail to an address in domain example.com
for which I do email processing. Whether I do any SPF checking is
irrelevant to the forwarding problem. (I do SPF checking, SID/PRA
checking, and DomainKeys verification, but none of that matters.)
What do matter are that I receive the mail for example.com and that my
user wants it relayed to his account at BigIsp.com. This has always
been easy, and I do it for a bunch of domains.
When BigIsp.com turns on SPF checking, the mail I'm trying to relay to
my user at BigIsp.com is seen by BigIsp.com as mail with an @aol.com
MAILFROM coming from my server. SPF rejects the mail that my user has
paid me to relay and has paid BigIsp.com to receive.
SPF doing what it's supposed to do breaks this very common forwarding
of mail. THAT is the forwarding problem.
To flesh out why mail forwarding is common, in a typical scenario
example.com would involve multiple users receiving mail at addresses
in the same example.com domain while using a variety of destination
email accounts at a variety of providers.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
Gatekeeper, NetHeaven, Saratoga Springs, NY