spf-discuss
[Top] [All Lists]

Re: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as Historic - was: New SPF Council

2009-01-24 03:32:37
----- Original Message ----- From: "Don Lee" <spfdiscuss(_at_)caution(_dot_)icompute(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, January 24, 2009 1:29 AM
Subject: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as Historic - was: New SPF Council


I  would  not argue with your wishful thinking, but that's not what we
should deal with here.

I really don't think it a case of wishful thinking to suggest that moving the spec to 99/SPF as the primary request type over TXT. It is the logical path where things will eventually go.

My point was that it should take place now in the SPF spec, because it encourages the right behavior in implementations and guidance for those who implement SPF. The folks who implement DNS were kind enough to establish 99/SPF RRs for this very group, it might be nice for the SPF standard to keep moving things forward by promoting their use.

The standard needs to declare the long term goals and direction, and what
is "preferred" (i.e. "correct")  Putting the new RR in the new spec
is the right thing to do.

I disagree. A standard declares how stuff is done. It isn't a long term goal, it isn't a direction where things should go.

The standard should IMHO acknowledge the current install base from the experiment which was conducted. But that's just it: an experiment, which was useful, and which should end.

I see two ways forward:

1: do not declare sunset for SPF-in-TXT. Do mention TXT in an 'historic' section, but do not allow it in the protocol. Let the implementors decide how long they should support the RFC4408 experiment. Disadvantage: there will be DNS software which doesn't yet know how to handle the SPF RR.

2: do declare sunset for SPF-in-TXT. Advantage: everybody agrees on what time frame we're talking about. Disadvantage: if the protocol is slightly different, both versions need to be discussed.


That said, keeping the TXT records around is essential.  No matter how new
people's DNS servers are, changing thousands (or millions?) of domains will require work to be done by a very large number of people, and updating their
TXT RR to SPF RR is not likely to be on the top of their lists.

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.

Yes, this requires work, but it's not like it is a huge task. In many cases it will be changing 'TXT' in 'SPF', either using an editor or by mouse clicking a drop down box.

Some people will do so soon. No problem here, provided that they get enough time. Some people won't bother, ever. No problem here either. If they're not interested in SPF anymore, they aren't updating their record in any way, we shouldn't concern ourselves with them. Some people will postpone the work as long as they can, as long as they are allowed to. Give them ten years and they use eleven, give them 100 years and they won't ever do the job.


It is simply not going to be completed any time soon.

What is soon?

From my POV, we should push for the SPF RR, but recognize that the TXT
records are going to be required in any usable implementations for
a very long time.

What is a very long time?

You aren't talking about a couple of years, else you wouln't have needed to write your message. But what time frame do you have in mind, and please use numbers in correlation with the word 'years'.



-------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>