-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Julian
Mehnle
Sent: Wednesday, May 11, 2005 7:45 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] A new result code for harmless permanent
errors? (was: For SPF council review: Syntax error = Perm error...)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
Julian Mehnle wrote:
Can a mail setup that employs SPF be significantly worse,
security-wise, than a mail setup that doesn't? What kinds of security
implications do you mean? Those that put the entire system (or
significant parts thereof) at risk, or those that just cancel or
reduce the effectivity of SPF?
I mean the macro example that Wayne gave where a forger could cause an
error and get unknown instead of Fail in the classic spec.
So why is that a security problem? "unknown" is now "PermError", and I
doubt they will let the message pass on "PermError".
I'm trying to find a reasonable way to solve the security concern that
Wayne is rightly concerned about without scaring potential new adoptors
away.
If "not scaring away potential new adopters" is a top priority, we should
define an "ignore=(yes|no)" modifier (or "op=ignore", for Frank's sake) so
beginners can publish without _any_ potential negative effect whatsoever.
</sarcasm>
You see where this is going? We simply can't protect new adopters against
their own faults (what if they accidentally type "v=spf1 ... -all" instead
of "v=spf1 ... +all"?), and if they're going to be scared away by their
own errors, we can't (and shouldn't) help it.
If macros are so difficult to master, we should perhaps add a warning to
section 8, "Note: Like everything else in this specification, macros can
cause your mail to get rejected. Use them carefully and don't mix them
up!". ;-)
My bottom line, ignoring the sarcasm, is that publishing an SPF record should
not reduce the deliverability of messages sent from authorized sources.
I'm not worried about the technical types who would look at a rejection and try
and fix it. I'm worried about their bosses. I'm also worried about the many
VERY non-technical domain owners.
Both of these non-technical types are very likely to just give up to get their
mail through.
I'm less worried about this now that it appears likely the spec will be changed
so the PermError is no longer worse than Fail, but I think it could be better.
All along the way to where we are now, where there was a design trade where
adoption rate was a factor, SPF has leaned in the direction of supporting more
rapid adoption. While this has produced some problems, I think that overall,
it's been a good approach. It's why there are as many SPF records out there as
there are.
My preference is actually to go back to just the way it was in the SPF classic
specs, but whatever the council decides, I will support.
Scott K