spf-discuss
[Top] [All Lists]

RE: Explain please (Was: SPF Stats)

2005-07-05 15:10:55
On Tue, 2005-07-05 at 14:11 -0600, Commerco WebMaster wrote:
SPF caused failures *should* occur when someone is trying to send 
email from a given SMTP server, claiming to be MAIL FROM: a domain 
name that has not been authorized for said SMTP server via an SPF DNS 
TXT entry in the domain's zone file.  After all, that's what SPF does.

Your later comments seem to indicate that you've entirely missed the
problem here.

Think what happens when you send a mail to someone, for example, at a
virtually hosted domain, and your mail is forwarded to a real mailbox at
an ISP somewhere.

The mailhost which hosts that virtual domain is _normally_ going to send
your mail on to its final destination intact, and that includes the
reverse-path.

Then the final recipient, if they are strictly checking SPF, is going to
reject that genuinely forwarded mail because the mailhost which does the
forwarding _isn't_ explicitly listed as one of the valid hosts for the
original sender's domains.

The effect is that genuine mail is rejected. That's not a _good_ thing;
it's an unfortunate side-effect of the way SPF works. This is what SRS
was invented for -- SRS is the baroque method of rewriting sender
addresses to make the forwarded mail pass SPF checks again. This needs
to be implemented _everywhere_ that does forwarding, in order that valid
mail won't be lost.

Now, some would have you believe that this breakage _is_ a good thing.
They claim that they way the world has always worked is 'forgery' and
'abuse' and try to make out that it should never have been permitted.
But truly, the only reason for changing it is to make the original
invalid assumptions of SPF come true. 

Now, that's perfectly reasonable if it's actually _necessary_. I agree
100% with what you say here:
Change is a reality in every part of life, including the Internet.
The issue and goal in change is how to minimize the impact and
inconvenience of any change proposed so as to cause least
inconvenience for the largest numbers.

But the point is that such massive changes _aren't_ necessary. There are
plenty of alternative solutions which _don't_ require such massive
changes to the way the world works. So I disagree with your following
sentence, where you suggest that SPFv1 'achieves that goal handily'. 

SPFv1 requires massive changes to infrastructure which aren't actually
necessary in order to achieve the goals which SPF sets out to achieve.
Therefore it _doesn't_ achieve your stated goal, handily or otherwise.

Now, people are working on fixing the forwarding problem, by means of
SRS and other techniques. But _until_ that is done, SPF isn't viable.
You are putting the cart before the horse if you are pushing for IETF
blessing on SPFv1 before that problem is fixed.

You then go on to discuss the popularity of SPF. VHS is more popular
than Betamax -- what relevance has that? I certainly don't deny that SPF
has good marketing hype, and the fact that it's so easy to gloss over
the massive and fundamental flaw in it -- even to the extent that you
don't seem to have noticed it at all after following the discussion --
is very helpful in its marketing.

You also seem to suggest that because this is an SPF list, the primary
goal should be to encourage the adoption of SPF even when it's not the
best answer to the original problem we were trying to solve. I don't buy
that -- I don't think anyone here would claim that they would favour one
solution over another for anything but technical grounds.

There are people who are brought here, as I was many moons ago, because
of the hype which is spread about SPF and want to learn more about it. I
don't think it does them a service if it's entirely a love-fest without
any critical discussion and comparison with alternative methods. 

I'm not particularly tied to BATV, although it was the first alternative
method I implemented and so far the _only_ alternative method because I
haven't actually had any need to do anything else. You'll note that the
BATV draft doesn't even bear my name. _Any_ of the alternative methods
(other than SenderID which manages amazingly to be even more broken than
SPF) would be a viable alternative. If my occasional voice of dissent
causes even a few people to actually stop and think for themselves and
to do something other than SPF, then I believe I've done them a service.

-- 
dwmw2


<Prev in Thread] Current Thread [Next in Thread>