I like the scope idea. But maybe we would need "and" and "or" operators.
"m and s" - If m fails then fail. Do not process p.
"m or s" - If m fails but s passes then pass.
"m or s" - If m passes then pass. Do not process P.
"m and s" - If m passes but s fails then fail.
What if m is neutral and s fails? Do we return neutral or fail?
If "m or s" return neutral.
If "m and s" return fail.
What about this? Gets real hard!
"m or (s and p)"
What is "p" is not supported by the MTA (license issue)? Is it just
ignored? Acts like neutral?
To enforce the order, do we use "and then" and "else if". Or is the order
just as listed. By using "and" and "or" the order is not important (I
think). However the sender may know one or the other would take more DNS
lookup, so having that last may be preferred.
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
Commerco WebMaster
Sent: Friday, October 22, 2004 2:10 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] the Seth Hypothetical
William,
I like this scope idea from a publishers standpoint, as it tends to avoid
the issue of having many different version (v=spfx) records to support
(perhaps even concurrently).
Would it also be worth considering that the order of the sc= might serve as
an order of processing for SPF record processing servers? That way, if any
one scope processing implementation conflicts over another, the publisher
is able to explicitly state their preference by the order of the intended
behavior for their published records to take place by following the sc=
list order itself.
This could be further broadened to recommend the processing server has
direction as to the final processing result by using the same +/-/~/?
syntax that is followed in "all". In instances where a conflict may happen
by virtue of the published record, the earlier in the list still takes
precedent, irrespective of the +/-/~/? syntax. e.g.,
v=spf1 sc=-m,~s,p mx -all - the record applies for Mail-From, Submit, PRA
but would also mean that the processing order for the above mentioned
scopes would also be m,s,p and that if -m processing does not pass, the
whole transaction result is FAIL, whereas the ~s would not do
this. (Please forgive me in advance if I have selected an example where a
conflict could not conceivably happen or confused my +/-/~/? syntax - I
think I have them correct, but the above example is for illustration of a
point of operational concept and not a firm syntax definition).
By adopting this method of processing, I think that if conflicts occur
(either today or over time) in the way that a given scope must be
processed, the earlier of the scopes in the list of scopes would indicate
the one(s) the publisher would prefer be used by an SPF processing
server. In this way, a publisher can choose that one scope is followed
over another while still allowing the SPF processing server to maintain
processing integrity where errors or malicious records may be processed by
a publisher (e.g., an invalid or unsupported scope might be ignored by an
SPF record processing server).
In some respects, the scope concept with the suggested enhancements might
also serve to eliminate most of the political arguments by which this group
seems to have been stymied, because SPF publishers choose which "standard"
or "standards" they wish to follow (market acceptance and choice are good)
by their scope publishing choices.
After all, the whole reason SPF exists is really as a vehicle for the
publishers of SPF records to protect their domain name(s) from identity
theft and other consequential misuse of their networks. As some have
pointed out, the market should decide which of the several likely choices
that exist today should prevail. Scope might just be the vehicle to allow
that to naturally happen in time.
Best,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
At 10:41 AM 10/22/2004, you wrote:
On Fri, 22 Oct 2004, Meng Weng Wong wrote:
As Rand requested, I will add a modifier to v=spf1
indicating "do not interpret in PRA scope" so the purists
can be satisfied.
So help me out here, we want modifier - "don't interpret as PRA" and we
don't want modifier "only interpret as PRA"?
We should either be doing it with full scoping support or not and if not
then its only SPF Classic Mail-From that is supported for v=spf record.
As far as modifers for scoping syntax - I've posted about it at least
several times on this list and on MARID:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200408/1261.html
And its not new concept either as I found looking at year-old archives, it
was in origianl SPF draft from october 2003 as "scope" modifier.
So again going over it again - we add positional modifier that interprets
everything after it as applying to certain scope with default (no sc
modifier on record) meaning it applies only to SPF1 mail-from like we
currently have or possibly with default meaning it applies to any scope
(depending on what consensus on this list is for default).
Scopes as follows:
m = rfc2821 mail-from (spf classic)
h = hello
s = submit
i = ip ptr
p = microsoft pra
Examples as follows:
v=spf1 mx -all - current spf, default meaning (scope aware
programs
should interpret as "v=spf1 sc=m mx -all"?)
v=spf1 sc=m mx -all - the record only applies for mail-from scope
v=spf1 sc=p mx -all - the record only applies for PRA scope
v=spf1 sc=m,s,p mx -all - the record applies for Mail-From, Submit, PRA
v=spf1 sc=m mx -all sc=h ip4:192.168.0.0/24 -all - here we have mx for
SPF mail-from scope and 192.168.0.0/24 is for hello scope record
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
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