Ok, I'd like to take a step back and outline what I think are the
questions before us and the options available to us in terms of
compatibility between the original SPF proposal and the MARID Sender
ID proposal being worked on here.
There are two independent (but potentially interrelated) decisions to
take.
The first is: which of the following functinality (if any) do we wish
to provide. (In the following, Sender ID refers to
draft-ietf-marid-core/protocol and SPF refers to draft-mengwong-spf)
1) The ability to publish a record for a domain that will only be
processed by Sender ID implementations, and not by SPF
implementations
2) The ability to publish a record for a domain that will only be
processed by SPF implementations, and not by Sender ID
implementations
3) The ability to publish different SPF and Sender ID records for a
domain
Note that 3 effectively implies 1 and 2, since you can publish ?all
for one of the records.
My dual versioning proposal (see
http://www.imc.org/ietf-mxcomp/mail-archive/msg02361.html ) provides 1
and 3 (and therefore effectively 2 as well).
My null mechanism proposal (see
http://www.imc.org/ietf-mxcomp/mail-archive/msg02720.html ) provides
only 1.
The current status quo (in the IDs) provides none of the above.
My feeling is that it would be prudent to provide for at least 1. I'm
less concerned about 2 and 3 since Meng Weng Wong's backing of Sender
ID means, I think, that going forwards Sender ID replaces SPF, and
over time people will stop caring about SPF.
In the event that I'm wrong, and the SPF community choose to continue
work on developing SPF (with or without Meng), then they can always
modify the SPF standard to provide 2 and/or 3 -- we don't have to do
that here. (Eg the SPF community could adopt a new prefix to allow
them to publish SPF-only records if they see the need)
I think we should do at least 1, though. There is a deployed base of
SPF checkers. Whilst currently SPF checkers are probably mainly run
by people familliar with the work in this area, with the forthcoming
SpamAssassin 3 release there will probably be far more people who are
not active in the SPF community or MARID WG running SPF checkers.
These checkers may stay around for a long time.
Given there are concerns that there may be circumstances where it's
undesirable for a Sender ID record to be interpreted as an SPF record, I
think it would be foolhardy not to provide 1. If these concerns turn
out to be warranted, and we don't provide 1, then this will be a
barrier to publishing Sender ID records for some people.
So IMHO we need to do 1 unless we are _positive_ that these concerns
are unwarranted, or we are_positive_ that the deployed base of SPF
checkers will go away in a timely manner. 2 and 3 might be nice if
they happen to fall out of how we choose to implement 1, but probably
aren't worth worrying about if they don't.
The second decision to take is what to do about the SPF records that
have already been published.
We have two choices:
A) Existing SPF records are processed by Sender ID as if they were
Sender ID records. If the publishers don't like this, they'll
either have to remove their SPF records or, if functionality 2 or 3
above is available to them (either as a result of what we do here,
or as a result of future work in the SPF community) they can choose
to publish SPF-only records.
B) Existing SPF records are ignored by Sender ID. People who wish to
publish MARID records will have to make an explicit decision to do
so
Option A has the advantage that Sender ID benefits from the existing
base of published SPF records, which will in most cases be appropriate
Sender ID records, too. It has a cost for existing publishers of SPF
records in those (rare?) cases where the SPF record is not appropriate
for use as a Sender ID record, in that they will have to change (or
possibly withdraw) their SPF record, or risk having their mail
rejected. Personally, I think this cost is acceptable, since SPF
publishers were largely aware that this was a young standard, and was
subject to change. Certainly as far as ISPs go (which was, if I
understand correctly, Margaret Olson's concern) I'd be astonished if
any ISPs who have chosen to publish SPF records are not tracking work
in this area...
The status quo in the IDs is of course option A; both my proposals
also adopt option A.
My preference is for option A, but I'm not wedded to it. If we go for
option B, the obvious solution is simply to adopt a new prefix (eg
v=spf2 or probably better something like v=marid1). This will then
make SPF records and Sender ID records completely independent
(effectively providing functionality 1, 2 and 3 described above.)
Sorry for the length of this... Thoughts?
-roy