[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: warning to list

On Tue, 2004-10-26 at 17:52 -0700, Z wrote:
> David Woodhouse wrote
> >Right. SPF, if it's to work, requires the whole world to 'upgrade' to
> >make the initial flawed assumptions of SPF come true.
> >
> Your opinion. More qualified people disagree.

That wasn't an opinion. That was a statement of fact. My _opinion_ is
that it isn't ever going to happen, and that it's not worth the pain of
even trying when there are far better alternatives. Nobody with any real
clue has claimed that SPF's assumptions are true in the real world
today, and that strict SPF publishing and checking would not be throwing
away real mail today. To pick a few examples, since you're obviously
incapable of understanding the technical points without someone to lead

Meng Weng Wong (the inventor of SPF in its current form) doesn't
	"if we expect it will take 1 to 3 years for the world to
	upgrade, maybe we can take 1 to 3 years to move from
	proposed standard to draft standard to standard."
	 -- Meng Weng Wong

The people who invented the 'Sender Rewriting Scheme' which needs to be
deployed ubiquitously in order to make SPF work don't disagree:
	"In an SPF world, forwarders need to rewrite the return-path
	to stay in good standing."
	 -- http://spf.pobox.com/srspng.html

Even you yourself didn't seem to disagree on Monday when discussing the
vast number of sites out there who have not yet 'upgraded' to SPF's
Brave New World, and will probably never do so:

	Jeff Pitman wrote:
	> In other words, all forms of forwardin email address will be
	> down the toilet (sf.net, berlios.de, etc.).
	Only the ones people are not willing to fix, and breaking them
	is a good thing.

Sean Middleditch didn't seem to disagree either when he said "No. You
fix them" in response to the same mail from Jeff.

The only people who do seem to disagree are the enthusiastic but dim
people who jumped on the bandwagon because it seemed shiny, without
really thinking about it. Also perhaps those who are actively and
disingenuously avoiding the technical points on which they'll obviously
lose any argument, and resorting to ad hominem 'arguments'.

The other thing to recognise is that even if this SRS rewriting scheme,
where each forwarding host 'takes responsibility' for the mail it's
forwarding by rewriting the address, _does_ get deployed ubiquitously,
it destroys the information which SPF was originally meant to check.

Because any host can rewrite mail in such a way, and all you can
actually tell from an SPF pass is how much you can trust the individual
mail server which sent you the mail -- it has nothing to do with the
address the mail seems to originally come from, and _certainly_ nothing
to do with the address in the From: header. So after all this breakage,
SPF hasn't even managed to do anything more than saner options like CSV.

SPF is fundamentally flawed, and the IETF MARID working group was
disbanded. On the other hand, the STRIVERS working group is still very
much alive, developing the ideas around Yahoo's DomainKeys, Cisco's IIM,
etc. They should come up with a combined solution which gives all the
benefits purported by SPF without the breakage. That's what we should be

But since you obviously don't like the technical side of the discussion
(and given your complete lack of understanding, who can blame you for
that?) I'll leave you with another quote:

	"When banks start DomainKeys or S/MIME signing all outbound
	mail, I promise to give up SPF and Sender ID."
	 -- Meng Weng Wong.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]