Thus, it is evaluated after SPF1, but its results make sense even if
SPF1 is a FAIL. Let's also assume that SPF3 is designed to be a
1-query protocol, and it contains a signing key or something like
that, so there is no redirect=mechanism:
In typical protocol design world next version of protocol is expected to
do as much as its first version and more and be able to replace earlier
version. As such you should not expect that SPF3 would continue to exist
together with SPF1, what you should expect it that there would be period
of time (possibly quite long period) where they would but that
specification
would call for SPF3 to eventually replace SPF1.
So while I personally would like to see simpler 1-query protocol for SPF3,
I really don't see how that would happen in a way that allows it to provide
same functionality as SPF3. More then likely what you would expect from
SPF3
is that it would be fulfill goals of Unified SPF and introduce scopes, etc.
Note also that all Unified SPF scopes that we talked about (with
exception of PRA which is clearly not supported by SPF community) were
for SMTP Session and are then 2821 layer and not based on header checking.
As the domain owner, one has to plan how to publish their records as
to impose the lightest DNS load on themselves.
This means that they have to share the 400-bytes available in the TXT
space between the two SPF records. Let's assume that the two records
are 300 bytes each.
DNS is created to be lightweight distributed query protocol where the
result
data is small. As long as spf record is small, that is good but if you
start
talking about it taking 300 or 400-bytes record and assume that most
records
would be like that, then its no longer good idea to keep SPF in the DNS and
its better for it to have information service on its own
Given the design of the mechanisms, the only possible plan is:
1. Publish SPF3 in full in the TXT record
I would say its probably fair view given direction of SPF (found even in
current spf specifications) to assume that SPF3 *WILL NOT USE* TXT record
and will likely use SPF DNS record type.
2. Publish 100 bytes of the SPF1 record and extend it with redirect=
This would work. But at the time SPF3 is invented, SPF1 is very
popular, and the installed base of SPF checkers is very large.
This means that just by publishing SPF3, the domain owner will double
the number of queries received from the installed base of SPF checkers.
Lets differentiate between number of queries and number of answers and
especially between data received in those answers. Remember also that
negative queries on specific record types can easily be cached. In
other words I advice you to read DNS specification and you'll understand
that its not as bad as you think even if two queries have to be made for
SPF3 and then for SPF1.
On the other hand, if the SPF1+3 checkers know about the ospf3=
extension in the SPF record, the domain owner could take the following
decision:
SPF1 checker would have no reason to know about SPF3 record (it does not
know how to interpret it easily). On the other hand SPF3 checker wants
to see SPF3 record first and if it is there, it has no reason to check
SPF1 record. But while "ospf3=" extension is BAD idea for SPF1 records,
its not bad idea to allow ->spf3 record<- to refer to older spf1 record
and in that way allow administrator to maintain "shared" record part
that would be understand by both spf1 and spf3.
1. Publish the 300 byte SPF1 record at the top domain, and add ospf3=_s3
2. Publish the 300 byte SPF3 record at _s3.domain.com
See my comments why it would be bad if SPF1 and SPF3 records are both so
large - its not good for dns.
Now, by publishing a new SPF record, the number of queries seen from
the large installed base of SPF1 checkers is the same as before,
except that each response is 10 bytes longer.
So what good is that if SPF1 has no use of it?
The number of queries to _s3.domain.com would slowly ramp up as the
adoption of SPF3 grows.
So what is the different between that and having separate SPF3 record
where SPF1 record is not even checked by SPF3 checker.
The SPF3 checkers already know to look for spf_also_publishes["spf3"]
if we specify the o*= extension in the SPF1 check.
SPF3 checker has no reason to use spf1 record if spf3 record already
exists.
I am assuming that an MTA vendor would use an SPF3 implementation that
are also supports SPF1, so the same library is called both for the
SPF1 check as for the SPF3 check. Thus, it will be aware of the o*=
extension.
In such a case you should assume it'll do SPF1 check if SPF3 record is
not there and if its there, then SPF3 record record would be used instead.
The SPF3 specification would have to provide guidance to the
implementors to look for an ospf3= keyword if an v=spf1 record is found.
If the SPF3 does not specify such guidance, the ospf3= makes almost no
sense.
SPF3 can have its own syntax that would explain if and how to use existing
SPF1 record if its there. Its way too early to talk about that right now.
The cost of not guiding implementors to look for ospf3= is that
adoption of SPF3 will be slowed by the fact that a domain that wishes
to publish SPF3 would double their DNS costs for very little or no
benefit,
until the proliferation of SPF3 checkers becomes comparable to the
proliferation of SPF1 checkers.
Again I strongly advise you to read more about DNS so you would understand
why above is to say the least not accurate.
The alternative would be for SPF3 records to be specified with a
residence at _spf3.domain.com. Unfortunately this means that MTAs
would have to "hunt", first at domain.com for an SPF1 record, and then
at _s3.domain.com for an SPF3 record.
It need not hunt there if it is an SPF3 specification and needs to find
SPF3 record first. In that case it "needs to hunt" only for SPF1 record
if SPF3 is not found. That is how you would expect next version of the
protocol to be implemented (and not only in case of SPF).
This "hunting" will not go well with the regulatory bodies that have
to promote SPF3 to the standard track.
The above statement is just wrong. Standards bodies will in fact hate idea
of hunting for spf1 record first.
So, without an extension like o= in SPF1, the barrier to entry of
future DNS-based methods is much higher than with the o= extension.
Again, the above is wrong and based on incorrect understand of how dns
operates and how protocol are extended.
This is because SPF was the first to hog the top-level TXT space. If
it was another protocol, it would be sensible for that protocol to
make these kinds of provisions for the future methods.
That however is correct. But SPF designers for the most part failed to do
it and its too late now.
This o*= extension would have been much harder to implement if Sender
ID had been successful and if it used the top level TXT record,
because the o* function would have to be built into Sender ID as well
as SPF.
I think it is a priviledge for SPF to be allowed to use the limited
real estate in the top-level record, and with priviledge, responsible
use and planning is needed.
Nobody "allowed" SPF to usew what you call top-level txt record, SPF people
started using unilaterally. DNS protocol experts all uniformly reject
this and will only support spf provisionally as long as it is going to
move towards using its own separate record type.
I would however agree with you about need for responsible use and need
for planning, but its already too late as SPF failed to do so.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com