This is an issue that the WG was supposed to have decided upon some
time ago, but I've seen no discussion on this.
Currently MARID records (as defined by draft-ietf-marid-protocol-00)
and SPF records (as defined by draft-mengwong-spf-01) are not
distinguishable. Given they are broadly compatible, this isn't a
major problem, but they are not semantically equivalent since they
check different identifies: the PRA in the case of MARID and the MAIL
FROM (usually; or the HELO in the case of <>) for SPF. So I contend
that it _is_ still a problem.
My focus here is people publishing MARID records which they do not
wish to be evaluated by the deployed (and to be deployed [1]) base of
SPF checkers conforming to -spf-01. I'm not considering the (IMHO
smaller) problem of existing records with -spf-01 semantics being
interpreted by a MARID-compliant checker.[2]
I made a proposal in
http://www.imc.org/ietf-mxcomp/mail-archive/msg02361.html of a way to
handle this, which no-one followed up on; I link to it here in case
anyone missed it.
I'd like to now make an alternative proposal:
Add a new mechanism 'null' to MARID, the null (or no-op) mechanism.
This mechanism is the converse of 'all'; it never matches.
A publisher who wishes to ensure that their records are not
interpreted by systems conforming to -spf-01 can easily use this as
the first mechanism in their MARID record. Since 'null' is not a
valid mechanism in -spf-01, an SPF checker will see an unknown
mechanism and return 'unknown', essentially ignoring the MARID record.
I don't see most people caring. Indeed, I suspect most people will be
happy for -spf-01 checks to be carried out on their MARID records.
But I do think that some people may have legitimate reasons for
caring, and that the issue should be addressed (or at least
considered)...
-roy
[1] SpamAssassin 3.0, which is expected to be released in about a
month's time, supports SPF checks if Mail::SPF::Query is installed.
AIUI Mail::SPF::Query is fairly close to an implementation of the
check_host() function; however SpamAssassin 3.0 will pass it the MAIL
FROM identify, not the PRA, resulting in SPF semantics.
[2] A lesser problem because people who have already published SPF
records at this point in time are early adopters, who are likely to be
aware that they're implementing a mechanism that's subject to change,
and can be expected to be reasonably likely to review the records
they've published in the light of the MARID specifications.