...... Original Message .......
On Sun, 27 Mar 2005 11:24:23 -0500 Radu Hociung <radu(_at_)ohmi(_dot_)org>
wrote:
Chris Haynes wrote:
1) Distinguishing the new record from Sender-ID records: There was an
optimistic
suggestion that Microsoft should be told to change their identification
to make
way for this new SPF version. This would not happen, but it is not
necessary.
SPF has the policy prefix form v=spf1. Sender-ID uses both a different
syntax
and a different version number - so the two are distinguishable. All you
would
have to do is get agreement within the SPF community on the version
number to
use for the version with the mask mechanism in it and it would not
interfere
with Sender-ID.
There was no talk of version numbers, as they do not need to change.
The suggestion was that the PRA mechanism get its own dedicate hostname
prefix (_{whatever}.domain.com) if a spf1 policy is present.
The reason is technical: the DNS reply packet has a limited amount of
payload capacity. This may be very small, in the case of numerous
authoritative records. Combined with the load sharing features of (most)
DNS server software, it would mean that if the ammount of TXT data found
for a host name exceeds the UDP packet size, the DNS software may do
load-balancing, and omit one of th TXT records, at random.
You can see how this hurts both SPF1 and SenderID equally, and this is
counter productive.
This exact point was extensively discussed on MXCOMP and a rough consensus
on the current approach was reached. Even if the entire archive is to much
to swallow (I understand), reviewing that discussion might be fruitful.
Since an MTA system that implements PRA would likely (necessarily)
implement SPF too, and since the PRA evaluation depends on a successful
SPF evaluation, it is easy to see that ideally, PRA should allow SPF to
use the DNS packet space as efficiently as possible. To get to the PRA
check, the MTA has to expand the SPF packet completely. SPF is the front
line if you wish. So, would it not make sense that PRA leave as much of
the DNS packet space to SPF, in order to minimize the queries that SPF
must do? Whether SPF requires one more query to resolve (for fetching a
record spread over more _spf{number} extensions due to less space
available in the first packet, or PRA having to do another query when
the SPF expanded succesfully are not the same thing. The extra query
done by SPF is more expensive than the extra query done by PRA, because
SPF is on the front line, and the number of evaluations required by PRA
is (much) smaller than the number of evaluations done by SPF. Thus, a
(much) lower chance that the PRA query is even executed.
What leads you to believe this? IIRC the Sender ID specs don't work this
way.
There will be those that will say that 1 more query doesn't matter when
you are already doing a bunch.
But, keeping in mind that currently most (approx 84%) existing SPF
records require fewer than 7 mechanisms, and that sharing the record
space with PRA at the domain.com allows each of SPF and PRA to use about
200-bytes of that packet:
When most records out there are compiled, because they happen to be
hosted on a compiling DNS service, and this will happen eventually, if
SPF and PRA achieve success (note the success of SPF will prompt DNS
services to optimize their costs by installing compilers, not the other
way around), many of those 84% of the records will compile into IP-list
records that are longer than 200-bytes.
That means that when the SPF and PRA compilers use the available space
of 200 bytes each, they will each have to expand their output such that
they require 3 queries total for a SPF+PRA combination that used to
require 2 queries before the compiler was added. This puts "the brakes"
on installing compilers. In turn it puts the brakes on saving DNS
traffic. In turn it puts the brakes on SPF and PRA. To some degree, I
concur.
Whereas if we separated them now in the backwards compatible way I
showed, the 84% would require 2 queries after compile, instead of 3
queries. When you're talking small numbers like that, a 50% unrealized
savings does not look very good.
I understand that you're going from 7 queries to 3 queries, but you
could go from 7 to 2, for essentially effort other than the willigness
to look far enough into the future and plan for it. Since we pretend to
be so much better than Microsoft, why don't we suggest this, and perhaps
earn some (more) of their respect in the process. Please let's not make
this a discussion of SPF vs. Microsoft. Let's keep it at doing what's
best for the future. If we cannot agree on what's best for the future,
we should drop the issue and live with the inefficiency. Politics has
nearly killed SPF once, why try that again? Thank you kindly.
Good point. I would suggest to you that any interaction with Microsoft is
inherently politically charged at this point.
Separating the two record types to their own 'hostnames' is a way for
the two standards to coexist and cooperate in lowering the overall cost
of the solution.
It does, however, cause Sender ID to have to ALWAYS look two places instead
of one for TXT records. I doubt they would regard this as an effiency.
Scott Kitterman