On Wed, 2004-09-15 at 16:31 -0400, Stuart D. Gathman wrote:
Accepting forwards from any domain with an SPF record seems like a bad
policy on the receivers part. A more reasonable policy would be to accept
forwards only from forwarders trusted to supply a correct Received-SPF
header.
How do you know it's a forward -- especially if it's a malicious fake?
Who says it'll actually start with 'SRS0'?
The usual objection is that large mail providers have no application in
place to allow their millions of users to designate forwarders. I am
suggesting that such an application would be very helpful. Forwarders
need to be authenticated too.
It's not a problem which is actually solvable in the wild. You can't
attempt to massage SPF into an end-to-end trust system in that way --
it's uncertain enough with the number of 'unknown' results which have to
be deployed, without making that uncertainty exponentially worse by
extrapolating it over multiple hops.
As Seth correctly points out, SPF can _only_ give you some indication of
how much you should trust the _present_ SMTP client, by telling you who
claims to be responsible for it.
Even if some kind of trust-chaining scheme weren't wildly impractical,
my point is that it's also just as sane to apply it to a version of SPF
where the 'trust key' isn't actually taken from the domain name of the
reverse-path.
Once it's actually deployed and people have reacted to it, you can't do
anything with SPF that you couldn't do with a scheme which just checked
some other characteristic of the mail server, like its HELO greeting or
the signatures on its TLS certificate. Which means all the breakage, and
the apparent need to deploy SRS, are rendered entirely pointless.
If all you're going to manage to do in the end is authenticate the one
SMTP client who is sending you the mail, then bite the bullet and
address that task sanely. There should be no need for an 'unknown' or
'softfail' result in that kind of identification.
--
dwmw2