Re: Modifications to SPF for Mask function
2005-03-28 11:02:38
Scott Kitterman wrote:
...... Original Message .......
On Sun, 27 Mar 2005 14:46:09 -0500 Radu Hociung <radu(_at_)ohmi(_dot_)org>
wrote:
Scott Kitterman wrote:
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.
I'll try to find it and understand the decision.
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.
It wouldn't... the backwards compatible way I suggested is:
Query domain.com
If it contains SPF1,
Query _pra.domain.com
else
Quit
Yes, it does look like 2 queries. But assuming that the system
implementing PRA also implements SPF, the result of the domain.com query
costs nothing, as the result is already in the local DNS cache.
Why do you make the assumption that anyone who checks PRA will also check
SPF?
Because it's only reasonable that SPF be used to reject the obvious
(forged) SPAM before DATA, and the non-envelope-forged phishing attacks
after DATA. I see no value in accepting a forged envelope, just to do
header checks on the forgery.
Perhaps I don't understand spf2/pra/mfrom/etc well enough. I thought it
depends on SPF, but not that it replaces it.
OK. Your example proves my point. If MS were to move their SPF2.0/
records (I assume you would want SPF2.0/mfrom records to move too) then
there would always be an additional DNS query required. Whether you count
it 0 to 1 or 1 to 2, it's still one more.
Not always. Like I said. Short records that fit in a DNS response will
be put side by side in two TXT at domain.com. If they get too long, such
that they don't both fully fit in the packet, one should be moved,
rather than having to apply daisy-chaining to both of them.
So PRA would only do a second query if the first found an SPF. 90% of
the time, both records will be at domain.com and the second query is
avoided.
BTW, in your proposal, where do you suggest SPF2.0/mfrom records be put?
My proposal mostly says "somewhere else". It's for them to figure out
where, once they see value in moving it. I used _pra only as an example,
but obviously the SPF2 crowd should think about this and chose something
that makes sense.
This also affords the SPF/PRA compilers the opportunity to put both
records in the domain.com space if they are small enough, and in that
case, 1 query finds both.
So really it is only 1 expensive query, and one cheap/free query if the
records are big.
So what you propose is that the SPF2.0/pra record only move if it's big?
How would a receiver know if the lack of a SPF2.0/pra record at example.com
was because there was no SPF2.0/pra record or because it was a big record
located at _pra.example.com? Wouldn't they have to do a TXT query at
_pra.example.com to find out?
Yes. That's where the second query comes in. Let's use numbers:
If you have a 400-byte SPF record (IP list) and a 400-byte SPF2 record
(whatever), they would not both fit at top level example.com. So, both
the spfcompiler and the spf2compiler would try to share the space by
splitting each of the records into 2 200-byte records, and daisy chain
them with redirects. In total, that is 3 queries to solve both SPF and SPF2.
If they were to specify the alternate location for SPF2, the 400-byte
SPF record would fully fit in the query response for example.com, and
the 400-byte SPF2 record would fully fit at
_alternate_location.example.com. Ie, 2 queries.
The only potential trouble would be when you only have one simple SPF
record and no SPF2 record, as that would create a second query.
In this case, the DNS server which uses both SPF and SPF2 compilers, may
put in a neutral SPF2 record in the same packet as the SPF short record,
to avoid the second query.
If the records are published manually without a compiler, the risk of
both records not fitting is higher, becasuse the publisher probably
won't count bytes, and even if he does, he won't know how much space is
available. In that case, the DNS server would do the proper
load-balancing thing and respond to queries by randomly picking one of
the two records for the query reply. So now we have intermittent results
from both SPF and SPF2. At least when it was only SPF, the reply packet
would include the truncated bit, so you know you're missing something.
But because of load balancing, the truncated bit will not be set, and
you'll be left with the intermittent results.
Radu.
|
|