The choice involves some tradeoffs. We need to make sure that we
consider them as a set.
New record types have a history of taking a _very_ long time before
they gain widescale usability. Given the urgency of spam
control, this
is an important concern.
The other issue to consider is risk of fracturing the spec. This is
a competative enviornment. If the choice is between a spec I can deploy
today and a spec that will be agreed in two, three ten years, when the
IETF feels like doing something then it is a very easy one to make.
I believe the following criteria should be met:
1) Immediate deployability
2) Content of the record MUST be text based so that parsing outside the
context of DNS infrastructure is easy.
3) A policy record should not be confused with other records
4) It should be possible to request only records of type policy
5) Cache friendly.
I know that some people want a DNS syntax for the record. In my view
that would be the death of any spec. The implementation community
are not keen on XML, but they will utterly loathe a binary format.
The DNS binary syntax is not as bad as ASN.1 but it is pretty yucky.
The other big problem with a binary syntax is the lack of flexibility.
It is pretty easy to design a text based format in an extensible way.
Sure, this is not how the DNS was designed. I really don't think that
the original design is of interest here.
There are four basic approaches possible:
1) SPF approach, hijack the TXT record for use by SPF
I don't like this approach because it fails criteria (3,4).
2) TXT record with prefix label, e.g. _spf, _ep
This fills all the requirements, with the possible exception
of (1) since some DNS configurations reject labels with
underscores. I think in the context of an IETF proposal we
can get these fixed.
3) New RR with text encoding
Critical issue here is when the RR is known and fixed. If this
takes more than 3 months for the code point to be known the idea
is dead.
4) New RR with DNS binary encoding
Sure this meets the academic purity of the DNS design. It also
means that we have to wait five years before deployment can
happen. It is very unlikely that the email filter companies
would use the IETF suggestion rather than a defacto SPF or
callerID deployment.
I would like to go the _spf route. OK we can be tactful and call it
_lmap. But we should decide on the code point NOW so that people
who are deploying TODAY can build in code that makes allowances.
It is not too difficult to write code that checks for _lmap, _ep
(callerID prefix) and unprefixed SPF records in that order. But
we need to tell people what to do quickly.
The unspoken issue that people have raised is one of control. If
people can just extend the DNS at will by defining new prefixes
bad things might happen. I don't accept that argument.
Phill