On Fri, 2004-08-20 at 05:48, wayne wrote:
In <ADCBD237-F26B-11D8-A105-000A95BDB38A(_at_)corp(_dot_)earthlink(_dot_)net>
Tripp Cox <tripp(_at_)corp(_dot_)earthlink(_dot_)net> writes:
On Aug 20, 2004, at 12:11 AM, wayne wrote:
The creation of a minor version number was mandated during the IETF-60
session. No semantics of what the minor version number should do were
given. I've talked with both Mark and Meng about this, and we all
agree that we can't think of any use for a minor version, which was
why it wasn't there in the first place.
As SPF 2.0 is a policy that speaks only to how to deal with the PRA, I
could see a minor version being useful if additional policy classes
are added.
There is no need to use the minor version for the ability to extend
the SPF2 records to different scopes.
The current marid-protocol I-D gives the following ABNF for the
version token:
version = "spf2." ver-minor "/pra" [ ver-ext ]
ver-minor = 1*DIGIT
ver-ext = "," *VCHAR
So, things like "spf2.0/pra,mailfrom" and "spf2.0/pra,helo" are
perfectly valid.
There is a way to define the mail channel with a single DNS lookup, but
this TXT script seems like a dog with a bone. If there is to be
extensions considered, then excluding PRA should be one such
consideration, if nothing else then to be excluded from repudiations
based upon RFC2822 content. This also helps prevent the need for "open"
lists to allow the use of a return mailbox. I can see many reasons for
not including PRA.
So should "spf2.0/mailfrom" as example.
version = "spf2." ver-minor [scope]
ver-minor = 1*DIGIT
scope = "/" *VCHAR ","
-Doug