On Thu, Nov 11, 2004 at 05:37:21PM -0600, wayne wrote:
As an example to start discussing: The two low bits (------10) could signal:
00: actively not participating in email (alias for "-all" ?)
01: check rfc821 headers only
10: check rfc822 headers only
11: check either or both
Querying for version 0x03 returns 0x01, 0x02 or 0x03 records.
Querying for version 0x01 returns 0x01 or 0x03 records but not 0x02.
0x00 will always be returned (if present) to any query. This could be
an implicit record (our much desired wildcard) if and when DNS servers
are configured to provide it.
DNS queries don't work this way. You can not do subqueries based off
data in the RR, only the domain name, the RR type and the Class (which,
effectively, is always "IN").
Ack. No over-the-wire reduction. Still, an SPF client could use the
two bits to determine what to do.
Creating a new RR with a version number wouldn't be of any real use.
It wouldn't save many bytes, and it would require more changes to SPF
implementations and DNS servers than just re-using the TXT format.
It would save some parsing. An SPF-classic parser wouldn't need to look
at versions with the lower bit cleared.
pseudo code:
if odd(spfrecord.version) then { ...}
in stead of
if stringcompare(txtrecord,"v=spf1 ",7) { ... }
Changing the parser to look at the entire SPF record in stead of the
TXT record from position 8 would not be a big problem me thinks?
In my opinion, it doesn't make any difference what format the new SPF
RR will be as it will never be widely used. In this case, I
completely agree with Phillip Hallam-Baker, Harry Katz, and Jim Lyon.
This is why there should be an expire date for using TXT records. When
the new record is assigned, and when the SPF RFC is finalized, that is
the time to announce end of SPF in TXT.
cheers,
Alex
--
I ask you to respect any "Reply-To" and "Mail-Follow-Up" headers. If
you reply to me off-list, you'd better tell me you're doing so. If
you don't, and if I reply to the list, that's your problem, not mine.