First of all, thanks Mark for a whole lot of work!
At the WG meeting in San Diego, a number of arguments were
cogently advanced regarding the change of version string.
I would like to comment on the proposed change.
Because v=spf1 strings were semantically associated with the
2821.mail-from parameter, and because Sender ID prefers the
2822.PRA/2821.SUBMITTER above 2821.mail-from, a change of
version string (to v=spf2 or suchlike) was proposed. This
change is intended to disambiguate SPF Classic from Sender
ID, to accommodate sender domains whose policies regarding
the PRA might differ from their policies regarding the
mail-from.
While such a change is, from the standpoint of architectural
purity, absolutely the correct thing to do, I fear that in
practice it may lead to confusion, needless duplication of
records, and a failure to achieve the intended objective.
In other words, it is my opinion that engineering
considerations do not weigh in favour of changing the string.
I particularly do not want to see a world where the norm is:
example.com TXT "v=spf1 a mx ptr"
example.com TXT "v=spf2 a mx ptr"
Both records would contain the same content, yet senders
might feel the need to publish both "just to be on the safe side".
Assuming that the email ecosystem adopts the recommendations
of this working group, I believe that the number of
scenarios which would benefit from a distinction between
v=spf1 and v=spf2 is practically nil. If I am right, and if
we change the string, I fear that implementors will complain
that we have inconvenienced them gratuitously. While it is
true that anyone who has already implemented SPF Classic
will need to make a number of changes in response to PRA and
SUBMITTER, changes that relate to the version string are of
a different order.
Therefore, I recommend that we do not change the version
string. To accommodate the rare (and so far hypothetical)
cases where disambiguation is desired, we can instead define
a scope modifier or scope macro which will serve the same
function at a much lower cost.
I do not feel particularly strongly about this. If the
working group as a whole feels that changing the string is a
wiser course of action than not changing it, I will not
press my objection further, especially in light of the
deadlines. I just want to share a point of view which I
feel is underrepresented.