Re: warning to list

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

 



David Woodhouse wrote:
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
  
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.

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

  
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.

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. They actually support SPF enthusisatically. Shame on you.
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.
Out of context again. I never said that SPF is "flawed". Shame on you again.
Sean Middleditch didn't seem to disagree either when he said "No. You
fix them" in response to the same mail from Jeff.
  
Here we go yet again.
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'.
  
At the last count, there are almost 200,000 domains publishing SPF records, including 
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?

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.
  
I'll buy that. How many domains are using DomainKeys or S/MIME for every and all mail they send ?
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.

Z

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux