I would also echo support for the dropping of the TXT RR in favor of
the SPF RR in DNS host files. As SPF moves from an experimental
phase to a standards track, the standard should certainly fully
encourage the adoption and use of the SPF RR created specifically for
its use by the DNS standards participants.
Given the issue discovered in DNS last year, which essentially
required suppliers of DNS server software to address and update their
software, one would think that any serious DNS operators would have
migrated to the new fixed DNS server versions. One would also think
that suppliers of DNS servers would also have added support for SPF
RR as a valid and accepted RR type in current DNS software per the
RFCs governing standards for DNS in their current releases. Thus on
most all DNS servers, one might conclude that there should already be
direct support the SPF RR.
The only other concern I could foresee regards support for the SPF RR
requests from SMTP server software suppliers already supporting
SPF. In order to continue to supporting existing host file records
not updated to the SPF RR, those servers must support a "dual track"
TXT and SPF RR for host files. That said, as part of the new
standard, it should be made clear that the SPF RR must be the first
checked RR followed by the TXT RR.
Once those who maintain SPF TXT records in their host files begin to
observe the trend for SPF RR requests being issued first and then
followed by the TXT RR requests (presuming they do not have an SPF RR
setup in their host files), they will add the SPF RR to avoid the
extra request pattern on their DNS servers.
Thus over time, the need to maintain a TXT record in host files
should naturally diminish without impacting or breaking existing environments.
Best,
Alan Maitland
At 10:10 AM 1/20/2009, you wrote:
Alex van den Bogaerdt wrote:
2: get rid of TXT. It was nice to experiment with, but now that we
have our own resource record type, it should be used exclusively.
During some amount of time, say a couple of years, the TXT RR could
function as a fall back, but it should be clear that this is going
to be phased out.
If that's the way to go, perhaps it is better to do it right in the
new RFC. It should aim at the standard track, replacing the experimental 4408.
Of course, I agree that the new spec shall strive for compatibility
and ease of migration as far as possible. However, we must not fear
to learn lessons from the experimental phase. I think John Leslie
expresses the thoughts of many of the well-disposed SPF users when he writes:
" SPF has been due for its 2-year review (of Experimental Status)
" for a while now. Hopefully it will get a useful review, and I choose
" to hope it will get enough of an overhaul to become useful.
http://www.irtf.org/pipermail/asrg/2009-January/004525.html
-------------------------------------------
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