At 15:32 24/01/2009 Saturday, Alex van den Bogaerdt wrote:
----- Original Message ----- From: "Scott Kitterman"
<scott(_at_)kitterman(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, January 24, 2009 3:29 PM
Subject: Re: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as
Historic - was: New SPF Council
On Sat, 24 Jan 2009 09:29:32 +0100 "Alex van den Bogaerdt"
<alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:
...
What is essential is that SPF policies in TXT records go away, or at least
become obsolete. Checking for both RR's is a waste, keeping TXT and not
SPF
is not good either (TXT records are used for other purposes). That leaves
keeping SPF records and stop using SPF policies in TXT records.
...
Checking both RRs is a waste is right. When we did RFC 4408, the general
consenus was that type SPF would not get significant traction.
at that point in time: yes.
and still today to a large extent
So far
that's holding up well. I don't see why this will change no matter what we
write in an RFC.
So far I've seen rehashes of the same discussions we had 3 or 4 years ago
about theoretical goodnes of a dedicated RR type. No one has yet addressed
the question of how to do the transition. Vague assertions aren't going to
get it.
I have addressed the issue. Briefly perhaps, but it is certainly not true that
it hasn't been addressed.
Using TXT is sometimes troublesome. This is even mentioned in the RFC. It is
my believe that the SPF RR was asked for to overcome this problem. I
(reluctantly) agreed that when the drafts were published, it was too soon to
require the use of SPF records instead of TXT records.
That was then. Now is now.
There is a resource record type, bind (and probably other DNS software as
well?) supports it, its handling is the same as you do with TXT records.
Provided that the software can handle it, domains can easily transition to
using SPF records when they need to. They need to be motivated to do so,
which is IMHO reached by declaring the use of TXT as obsolete
but only supported in bind 9.4 and above
still unfortunately rare in the wild {none of my hosting or secondary {remotely
provided by others} dns servers support it as yet
but the point is moot as long as clients try SPF first and only TXT when SPF
fails
it will be easy for dns providers to retire TXT for SPF when they see no more
lookups for TXT
hell it should be possible for many to retire TXT when their own server starts
providing SPF
only reason for providing both is
A broken/old clients
B broken/old caching dns servers
both will disappear in time {but only in time not through saying it must be so}
This message to the IETF is not a kind invitation move SPF onto the
standards track. It's an attempt to kill SPF and Sender ID both.
I disagree. The last paragraph basically asks us to resolve the conflict and
update the specifications -> spf should continue, but not in 4408.
i think we should be attempting to come up with an spf successor/replacement
that at client and provider level should separate {as in distinguishable} but
largely backward compatible
so that clients and providers can migrate easily {limited differences in syntax
and thus limited re-writing}
and both clients an providers can continue to support existing format also {in
absence of newer format}
I feel very strongly that we need to limit ourselves to fixing protocol
bugs right now. The only one I'm aware of is the treatment of all DNS
errors as temporary when some aren't.
I consider dealing with both TXT and SPF RR's a bug.
Let's deal with protocol enhancements later.
Agreed. But ditching TXT is not such an enhancement IMHO.
I think this is exactly when we should deal with protocol enhancements
such as the suggested extra return code for dns errors of a non temporary
nature {i saw it mentioned didn't see it detailed}
extra return code for never-exists {as opposed to fails spf-validity check}
and adding to helo and mfrom realms the pra realm to supercede sender-id for
those that want this feature included
{for those not wanting to use it it can also be easily excluded from that
providers spf record}
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com