Existing spf1 systems would not parse this.
Guy
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Mark
Shewmaker
Sent: Saturday, October 30, 2004 3:59 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Using "v=spf1/scope1,scope2,scope3 " as a scoping
syntax
I have an alternative suggestion to ponder for modifying the spf1 spec
(well, Wayne's spec, if we can convince him to submit it. :-) ), to
incorporating scoping.
It's pretty much the unified syntax, really.
This is the idea:
1. Allow multiple scopes via the format: "v=spf1/scope1,scope2,scope3 "
for all RR types. (TXT and future SPF RRs--yes, that's a plural
"RR".)
2. A record listing no scopes is taken in the context of that RR's
implied scope.
3. The implied scopes for the various RRs:
Defined: (Except that there is no "SPF" RR yet.)
TXT: The latest version of "mfrom"
SPF: The latest version of "mfrom"
Undefined, but implied for the future:
SPF-any: "any" scope. Matches the latest version
of any scope not otherwise described.
SPF-pra: The latest version of "pra"
SPF-helo: The latest version of "helo"
...
Maybe the scopes should be m,p,h instead of mfrom,pra,helo, or
perhaps receivers should consider them equivalent.
4. It is RECOMMENDED that publishers use the format "v=spf1 "
instead of "v=spf1/implied-scope-name " for singly-scoped records.
5. It is RECOMMENDED that publishers publishing an explicitly-scoped
TXT record containing "mfrom" scope also publish an equivalent
implicitly-scoped TXT record.
6. Publishers MUST NOT publish explicitly-scoped records that duplicate
scopes with other explicitly-scoped records within the same RR type.
(Ie, those duplicate scope definitions are handled just as duplicate
spf records are now handled--with permerror.)
7. Implicitly-scoped records that duplicate scopes with
other records MUST be otherwise identical.
8. Explicitly-scoped records in SPF-* RR types may only include
scopes of different versions of the same type as the implied
scope.
(This allows for minor tweaks to the meaning of individual scopes,
so that you could have a PRA and PRA2 scope within SPF-PRA records.)
9. If a publisher publishes both a TXT record and SPF RR record, the
contents must be identical.
10. For recipients, non-TXT RR records override TXT records.
The upshot of all this is that:
1. We'd have wiggle-room for people to define a senderID-type PRA
scope in a separate document, without the need to bump the
version string.
2. All current records would still be compatible with current spf
libraries.
3. People publishing records can feel slightly safer that their
records will only be interpreted in the scopes they intended.
So this is a change in the sense that all libraries would have to be
updated, but not in the sense that it would change the meaning of any
currently-published records or any records that would be published
in the near future.
I think this is a better solution than doing scoping with modifiers, as
the latter would either require positional modifiers, (ugh), or it would
require allowing multiple spf records with differing scoping modifiers,
which is not backwards compatible with the current spf libraries that
would see that as duplicate records and return permerror.
(I do recognize however, that using positional modifiers and a more
difficult-to-read record may allow publishers to put a single
mfrom,pra,helo-scoped set of rules in one record instead of 3,
compressing things such that everything fits in UDP size requirements,
where that might not be possible with multiple TXT records.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com