I'm not going to weigh in on the underlying debate here, but I'm going
to inject some information that might be useful:
1) Domains with large records will overflow the UDP limit:
Domains with large records that want to publish large, different
records for under both v=spf1 and spf2.0/pra can do so as follows:
example.com. IN TXT "v=spf1 redirect=_spf1.%{d}"
example.com. IN TXT "spf2.0/pra redirect=_spf2.%{d}"
_spf1.example.com. IN TXT "v=spf1 ... some very long record here
..."
_spf2.example.com. IN TXT "spf2.0/pra ... some different very
long record here ..."
Yes, this will require two DNS lookups (though both can be cached the
same as the one, so any reasonable TTL makes this less of an issue).
Neither query will fall over to TCP (assuming the long records are
individually under the UDP limit)
2) Wildcards
All the major points about wildcards have been made: Essentially, they
don't work the way you'd like them to whether or not there is a prefix
-- it is the nature of DNS wildcards.
On the other hand, if a domain uses wildcard MX records, then wildcard
TXT and/or SPF2 records can be used to achieve a matching effect. See
the protocol-03 draft for an example and discussion of just this point.
I will only add here that publishing under a prefix or not makes no
difference - the use of wildcards has the same caveats and
difficulties.
3) Incorporating scope into the record format
Several schemes have been proposed on this list for incorporating
scoping into the protocol syntax. I will summarize them here:
3a) Put scopes in the <ver-ext> field
Proposed by Wayne in
http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html
This scheme replaces the "/pra" and <ver-ext> field in the version
string with a list of scopes. For example: "spf2.0/pra,mailfrom" or
"spf2.0/mailfrom". It applies to the whole record, so it only helps
domains with very large records if their v=spf1 and spf2.0/pra records
are otherwise the same. If the above two large records were the same,
this would look like:
example.com. IN TXT "spf2.0/pra,mailfrom ... some very
long record here ..."
If the large records are different, they'd still have to resort to the
method presented in (1) above.
3b) Add a scope macro %{e}
Originally in the Unified-SPF concept, but recently proposed by Meng
in http://www.imc.org/ietf-mxcomp/mail-archive/msg03663.html
This scheme adds a macro that is replaced with the identifier for the
scope being checked: "pra" or "mailfrom". It can be used with the
include: mechanism or redirect= modifier to incorporate different parts
into mostly common record:
example.com. IN TXT "spf2.0/pra ...common...
redirect=_%{e}.%{d}"
_pra.example.com. IN TXT "spf2.0/pra ... pra only stuff ..."
_mailfrom.example.com. IN TXT "spf2.0/pra ... mailfrom only stuff
..."
If the common mechanisms work, then only one DNS query needs to be
done. Otherwise, this basically devolves into the method presented in
(1) above.
3c) Add a scope modifier
Variations discussed in the past, recently proposed by William in
http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
This scheme adds a modifier that alters the applicable scope for the
following mechanisms until the next scope modifier. For the big
company case, this is only a help if bulk of the records for PRA and
MAILFROM are the same, and the common, plus all the difference, plus
the overhead of the scope modifier still fit in one record:
example.com. IN TXT "v=spf1 ... mailfrom only stuff ... "
"sc=pm ...common... "
"sc=m -all "
"sc=p ... pra only stuff ..."
If it doesn't fit, then it devolves into the method presented in (1)
above.
This idea has several structural problems: Modifiers would have to be
substantially reworked to achieve this "environment variable" like
behavior. The current document doesn't support such modifiers. Also,
this scheme has several important subtle restrictions to achieve
backward compatibility with existing SPF systems.
3-Summary)
For sites where records for Sender-ID and SPF are large, similar though
not the same, none of these methods is a win over the method in (1).
For sites with small, similar records, only (3c) has any advantage over
(1). For sites where the records are the same (claimed by many to be
the vast majority of sites), (3a) is the biggest win.
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com