David Woodhouse wrote:
The "flawed" is your opinion. A whole lot of people disagree. Of course, one can say that SMTP is horribly flawed. Few, if any, people would disagree.On Tue, 2004-10-26 at 17:52 -0700, Z wrote:David Woodhouse wroteRight. 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
Looks like a non-sequitur to me. What's the context of Wong's quote? It sounds to me like he's proposing that people adopt the method before it becomes a standard.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 you... Meng Weng Wong (the inventor of SPF in its current form) doesn't disagree: "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
Out of context. They actually support SPF enthusisatically. Shame on you.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
Out of context again. I never said that SPF is "flawed". Shame on you again.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.
Here we go yet again.Sean Middleditch didn't seem to disagree either when he said "No. You fix them" in response to the same mail from Jeff.
At the last count, there are almost 200,000 domains publishing SPF records, includingThe 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'.
altavista.com, amazon.com, aol.com , dyndns.org, earthlink.net ebay.com, gmail.com,
gnu.org, hushmail.com , livejournal.com, mail.com, motleyfool.com, oreilly.com,
oxford.ac.uk, perl.org, philzimmermann.com, sophos.com, spamassassin.org, spamhaus.org, etc.
You realize that you just called Phil Zimmerman, the spamassassin folks, and the google guys "dim", don't you?
I'll buy that. How many domains are using DomainKeys or S/MIME for every and all mail they send ?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 supporting. 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.
When will full adoption happen?
Aren't we back to your complaint that "needs to be deployed ubiquitously in order to work"?
Are you proposing that we discard any non -DomainKeys or -S/MIME mail tomorrow?
THAT I don't see happening in my lifetime expect by force of legislation.