To address a couple of questions that Andrew Newton raised in his
concensus statement.
1. Placement of TXT records.
The co-chairs find that the working group has not come to consensus on
the use of a record prefix vs TXT records at the zone apex and has not
reached consensus on how to address domains with wildcard MX records.
First off, I don't think anyone's suggested putting the records at the
_zone_ apex (ie the delegation point); I'm assuming that the chairs
have been spending too much time reading DNSSEC discussion on
namedroppers :-) The term 'zone apex' certainly seemed perfectly
reasonable to me on first reading, precisely for that reason...
The choice is: should the domain of the identity to be verified be
used as the owner name of the TXT record, or should the owner name be
a subdomain of that domain, constructed by prepending a suitable
prefix to the domain of the identity to be verified?
If we wish to support backward compatibility with deployed SPF records --
and I'll note that the statement is worded in such a way as to imply
the that the question is _how_ we will do this, not _whether_ we will
do this -- then of course placing the TXT record anywhere other than
at the domain of the identity in question places extra burden on
implementation by having to query for records in two places.
So I think that if we are going to seek backwards compatibility with
SPF then there should be an assumption towards putting the records in
the same place, all other things being equal.
In fact putting records in two different places whilst maintaining
backwards compatibility adds significant conceptual complexibility --
if a record might exist at either example.com or _ep.example.com then
what are the implications of someone forging mail from
foo(_at_)_ep(_dot_)example(_dot_)com ?
On to the second point, and how to achieve backward compatibility...
If we assume that the changes to SPF syntax and semantics are likely
to be relatively small between draft-mengwong-spf and the final
version of draft-ietf-marid-core (as is currently the case) then it
may well make sense for deployed SPF records to simply be interpreted
as if they were MARID records.
But there are differences between the two drafts; most notably the
identity being checked, and also a minor difference in the
specification of the mx mechanism.
There will, in a few weeks, very probably be a large number of systems
checking SPF records (as defined in draft-mengwong-spf) -- quite
possible a much larger community than the community that currently
publishes SPF records. The Spamassassin team are preparing for a 3.0
release, which will support SPF checks (though admitedly only if
Mail::SPF::Query is also installed).
Given MARID records are similar, but not identical, to SPF records,
and that it is at least possible that there will shortly be a large
number of SPF checkers in real world use, I'd like to propose the
following strategy:
MARID should define syntax versions 1 and 2 (identified by v=spf1 and
v=spf2) as identical. MARID-compliant implementations must interpret
both of these records identically, and must use the highest understood
version record if multiple versions are found (this is the same rule
as in SPF).
This gives a publisher three choices:
a. Publish a syntax version 1 record. This is a valid MARID record
and will also be interpreted by the deployed base of SPF checkers
according to the semantics of draft-mengwong-spf (assuming it is
syntactically also a valid SPF record)
b. Publish a syntax version 2 record. This is again a valid MARID
record, but will be ignored by the deployed SPF checkers.
c. Publish both. In this case, given the rule of using the highest
version record that is understood by the checker, MARID checkers will
use the syntax 2 record, and deployed SPF checkers will use the
version 1 record.
Thoughts?
-roy