In
<E7681555CD8A70448031D66D5E4D39E2F39B0B(_at_)red-msg01(_dot_)redmond(_dot_)3sharp(_dot_)com>
Devin Ganger <DevinG(_at_)3sharp(_dot_)com> writes:
Don Lee wrote:
The simpler we make publishing SPF, the easier it will be to drive
adoption. Ideally there should be *one* way to do it, and it should
be easy and straightforward. Anything that smacks of confusion or
doubt will be an obstacle. This thread is full of FUD.
I have to concur.
Yeah, I strongly agree also.
I think a large part of SPF's success over similar protocols like RMX,
DMP, FSV, etc. is the easy of creating SPF records.
This started with my suggestion that really, since many small domains
use their MX servers to do all their sending, there should be an
"mx-only" flag. Meng quickly expanded this idea into the mx mechanism
and similar things to make things easy. Meng said that he felt it was
far more important to put the complexity into libraries that would
have to be implemented by a few people, rather than forcing publishers
to jump through lots of hoops.
I strongly feel that this was the right decision.
Now you have some people promoting the use of spf2.0 records even
though the PRA has no technical advantages. Now you have some people
promoting type99 SPF records even though it has no technical
advantages.
This creates FUD and slows adoption.
... TXT records vs. type99 records to be enough of a
distraction that it wasn't worth it. Many seemed to think that they
would be required to replace their DNS infrastructure.
Unfortunately, for companies that are heavily invested in MS products,
this may well be true. Not only would they need to replace lots of
their DNS infrastructure to support type99 records, but they may well
have to replace the OS on any machine that checks SPF records with a
non-MS operating system. This would include both mail servers and
desk top machines that do spam checking on the email client.
I guess I don't understand why there's so much resistance to just
using TXT records.
From a technical point of view, using a different DNS RR type for each
different use is cleaner and, in theory, causes few problems. As a
result, there are quite a few people who find this reuse/abuse of TXT
records to be very ugly. Many of these people are very knowledgeable
and many are involved in the IETF.
In practice, the problems caused by using a new RR type far outweigh
the technically cleaner design.
In practice, the SPF RFC would never have been published if there
wasn't language in it that would make it at least appear that we could
transition from TXT to type99 records.
*sigh*
The more subtle problem with the way RFC4408 establishes the use of
type99 records is that it explicitly allows implementers to create
RFC-compliant implementations that can fail to locate and use
existing SPF records.
As with a lot of specifications, "quality of implementation" is an
important factor and it can not be dictated. Any implmentation that
only supports type99 records would be, IMHO, brain dead. Actually, I
think any implementation that supports type99 records in any way by
default is, at best, bad.
It's probably too late to do anything about it now, but it would
have been really nice to keep type99 records as experimental;
I think that pushing for the implementation of type99 records with
stuff like name servers and such would be very good. I can certainly
see that at some future date, a new version of SPF may support only
type99 records, and if we get stuff working now, this won't be a
problem.
For SPFv1, I think we shouldn't touch it.
-wayne
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735