ietf-mxcomp
[Top] [All Lists]

Re: change of version string

2004-08-10 11:46:52

In <p06110400bd3eb6b156f7(_at_)[67(_dot_)161(_dot_)18(_dot_)242]> Ted Hardie 
<hardie(_at_)qualcomm(_dot_)com> writes:

At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote:

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".

Both records do _not_ contain the same information.  The first
record has a target of MAIL_FROM; the second has a target
of PRA.  The fact that the strings "a mx ptr" happen to be
the same in both records does not change that fundamental
fact.

*sigh*

1) Meng said that they "contain the same content", not "contain the
   same information".  You appear to be confusing content with
   information.

2) Meng, and many others, have pointed out that in the vast majority
   of cases, the information *will* be the same and changing the
   version number will cause far more problems than it solves.


       The fact that the same IPv4 dotted quad might appear in
an MX record and NS record for example.com doesn't change
the fact that the records tell you different things about how
that domain's systems are set up.  The situation here is
parallel; it isn't as obvious because you're using the overloaded
TXT record rather than the new RR.

This has *NOTHING* to do with RR types.  The same problems would exist
if we were talking about changing

  example.com TXTspf1 "a mx ptr"
  example.com TXTspf2 "a mx ptr"

That is, deleting a few characters and moving a quote doesn't change
anything.


The huge problem with *just* changing the version string is that it
cuts off future expansion.

Earlier this spring, the co-chairs rules that 2822 identities would be
held off until 2821 identities could be finished, but that we would
return to 2822 identities.  It was made clear that people wanted both,
but the 2822 identities had not been tested (and still haven't), and
it wasn't clear how to check the 2822 identities without creating
large error rates (confirmed by the very limited testing done so far
on the PRA).

At the interim meeting this somehow magically got flipped (without a
confirmation of this decision on the mailing list) and now we are
working on 2822 identities.  Even so, it was made clear that people
wanted to test both.


By simply changing the version number, we are limiting out options on
how to proceed with 2821 checks.  


As I said here: http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html
the problems with both changing and not changing the version number
can be easily solved by falling back to SPF1 records if no SPF2 record
is published and by defining the Unified-SPF scope macro-variable in
the SPF2 record.


For the vast majority of people, publishing SPF1 records will be all
they need to do or worring about.  For those that require different
records for the PRA check vs the MAIL FROM and HELO checks, they can
publish SPF2 records.



-wayne


<Prev in Thread] Current Thread [Next in Thread>