Since the trolls seem to have appeared it might be a good idea to use a more
formal form of discourse where discussion is centered on issues raised and
logged in the way we do in OASIS and W3C standards groups (and some parts of
the IETF).
I'd like to raise the new record issue which was one of the comments that
Steve Bellovin raised. I think it is one of the issues most likely to cause
adoption issues and possibly interference between SPF and other protocols.
Option A - status quo
At present an spf record has the form:
aol.com. 255 IN TXT "v=spf1 ip4:152.163.225.0/24
ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24
ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24
ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
The only way to identify the record as being SPF is from the very start of
the TXT string, "v=spf1 ..."
Let us first set out the issues to address:
1) Ambiguity (in), can a record encoded for another purpose be mistaken for
an SPF record?
2) Ambiguity (out), can an SPF record be mistaken by another protocol?
3) Selection, is it possible to make a query that retrieves SPF records and
only SPF records
4) Efficiency, what is the size of the message returned?
5) Expediency, is there a delay in establishing the scheme?
6) Compatibility, is the scheme compatible with existing infrastructure?
7) Legitimacy, does the scheme help establish legitimacy.
The existing scheme addresses issues (1), (5) and (7) but does not seem to
address (2) or (3). If AOL were to add some extra TXT records to work with
some other scheme there could be no guarantee that SPF records might not be
mistaken for the new scheme unless the new scheme was spf aware in some
sense. There would be no way of asking for only the SPF relevant records and
so this would fail (3) and by extension (4).
The point I am trying to make here is that SPF must play nicely with other
protocols, including those that have not been invented. The arcanae of
network protocols comes largely from cases where this rule has been ignored.
Option B) New Resource Record.
aol.com. 255 IN SPF "ip4:152.163.225.0/24
ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24
ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24
ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
This nicely addresses issues 1,2,3,4 but scores terribly on 5.
To get a kosher DNS RR issued you have to go one of two routes. In theory
you can apply for a RR in a different section of number space without going
through IETF process. In practice this is unlikely to be allowed and even if
you succeed you then have a problem because the RR's they hand out are
severely disadvantaged, you cannot use them with the bitmask mechanism.
To get a kosher RR number you have to have an RFC that has achieved working
group consensus. This takes a minimum of 2 years. I see absolutely no
evidence that the IETF establishment is taking spam at all seriously, I do
not think that there is any prospect of getting a fast track. Even if they
did fasttrack the scheme it would still have to be approved by the DNS
Extensions working group which has a track record of delay - DNSSEC is still
undeployable after 14 years of work.
And of course you still have the problem (6) - new RRs are only usable after
the infrastructure has been upgraded.
What may suprise some is that getting an IETF RR does not help very much on
(7). The main thing that the big four ISPs agree on is that they do not want
the IETF anywhere near a proposed solution. At the Jamspam meeting I was
laughed at for even suggesting IETF as a suitable standards venue - and not
just by those you would expect.
Option C
A third option is to re-use the existing mechanism defined by the SRV
record. Essentially you use a DNS name that is not a legal domain name to
use as a selector for the item you want to retrieve. This scheme is I
beleive compeletely compatible with the existing DNS infrastructure since
even though underscore is not a legitimate DNS character, it is a
potentially a legitimate character in Heisod, Chaos or any of the other name
spaces the DNS might be asked to support.
_spf.aol.com. 255 IN TXT "ip4:152.163.225.0/24
ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24
ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24
ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
The nice thing about this scheme is that it meets ALL the requirements
1,2,3,4,5,6 and looks pretty good on 7.
The issue that Meng did bring up is the issue of ease of typing the entry. I
don't see why this has to be a major difficulty.
The other big payoff is that we can do a lot more with extensions to DNS in
general. One of the big problems we are facing with DNS is that it is not at
all well designed from the point of view of extensibility. The model they
have for extension is a narrow clique of priests making centralized changes.
It is a very pre-Web model.
I have spent a lot of the past year working on XML infrastructure, in
particular Web Services policy. Implementing something like SPF in Web
Services infrastructure is simple, you already have the hooks to encode data
like 'I am currently offering version 1, 1.2 and 2.0 of FOOBAR, after 1
April only 2.0 will be supported'. This is because Web Services has a
metadata infrastructure you can query for information on a protocol.
SPF is currently a really nice hack that solves one really big problem for
the Internet. What I would like to do is to take it to the next level so
that it becomes more than just a solution to one specific problem.
I would like to be able to co-opt the Yahoo domain keys plan into the same
framework, and the MTAMark work, and some other stuff we have been working
on to.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡