spf-discuss
[Top] [All Lists]

SPF-classic is spf-draft-200406.

2004-10-21 18:35:39
In <41780B3A(_dot_)3FBA(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann 
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:

No clear consensus wrt HELO tests, %h, default explanation,
and a Received-SPF header.  Whatever that means.

Yes there *is* clear consensus.  These issues were decided 6 months or
more ago and were put into spf-draft-200406.  The fact that a bunch of
new people have come in since then is *NOT* a good reason to re-open
such things and make incompatible changes to SPF-classic.


People keep acting as if SPF-classic hasn't been complete static for
the last 5 months and fairly static for the last 9 months.  People
keep acting as if we are creating a new standard from scratch and can
make any changes we want.

No.

If you want to make incompatible changes, create a SPFv2 spec.

I can't believe the amount of discussion that the removal of slashes
from the domain-spec has caused and/or creating new macro variables
such as %!.

There have been tests for domains with slashes in them in the spf test
suite since March.  See:
   http://www.midwestcs.com/spf/tests/tests_v2.0/test_parser.txt

Removing the slash from the domain spec is an incompatible change to
the semantics of spf-draft-200406.

Before anyone goes and makes an incompatible change to the spec, you
*MUST* justify why that change is important enough to warrant the
change.  Why in the world should I have to edit the SPF test suite and
change my SPF implementation just so that the ABNF in the spec can be a
little bit easier to write?

In the case of removing the slash, no one has even tried to justify
it.  Yeah, slashes in domain specs are not real important, but the
onus must be on those who think it should be changed to justify it.


Dito not much about the "validating evaluation" principle.  It
is IMHO a possible solution for many "common mistakes".  OTOH
it's a strict solution, stunts like removing %{h} or adding %!
are not more possible, if unknown macrochars are syntax errors.
We'd need a new SPF version in such cases.

We *had* this discussion many months ago.  You can't change the
semantics of the SPF records, which includes adding or deleting macro
variables and percent escapes, without changing the version number.
While the *syntax* can allow for extensions, the semantics requires
code updates on the receiving side.

After it was all said and done, the IETF created the MARID working
group, and we had the discussion all over again with the proponents of
XML saying that you could change the semantics, but no one showed how
this could be done without breaking compatibility.

Let's stop trying to raise old issues.


If something is in spf-draft-200406, then it should remain there
unless a very compelling reason is given to change it.  The reason
needs to be less compelling if something isn't used (e.g. unknown
mechanism), but even for things like that, we should be very cautious.


I can see writing an updated draft for SPF-classic to clean up the
language.  spf-draft-200406 could use a lot of cleanup.  I can't see
creating a new standard and saying that it is really the old standard.


-wayne