|
Re: Modifications to SPF for Mask function
2005-03-28 17:40:24
At 01:02 PM 3/28/2005 -0500, Radu wrote:
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.
This is one of those "inter-operability" items that needs to be
standardized in a way that does not favor one or another authentication
method. Let's see how this problem might be solved starting with
fundamental requirements, then moving to a specific implementation.
Fundamental Requirements:
9) Forwarders should minimize Internet traffic by rejecting forged messages
at the earliest opportunity.
Subordinate Requirements:
9a) DNS records should be set up so that a single DNS query using a domain
name from the SMTP envelope will suffice to reject most forgeries without
needing a data transfer.
9b) This should work also with domains that use a non-IP authentication
method, like DomainKeys. There should be one query that returns whatever
authentication information the domain chooses to provide, and that
information should be sufficient to reject a forged domain name.
9c) The first response should also indicate the number of additional
packets of authentication information which are available if needed.
I have some implementation ideas, but let's get the requirements right first.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *
|
|