From: Gary Levell
Sent: Thursday, July 08, 2004 8:28 AM
I agree with Roger, but with the caveat that we should not break existing
parsers, so the original post that I made still stands noting the obvious
issue Wayne highlighted that there was a parser by Hector Santos that
required
the modifiers to be at the end.
To re-iterate:
"v=spf1 mx -all scope=p +ip4:195.224.71.10/24 -all"
My take is that newer publishers working from the SPF spec are
entitled to
place the modifier whereever they like (so that Hectors'
implementation will
need to be upgraded anyway).
Which will break existing parsers. This is the risk inherent in early
adoption. Some tweaks will be necessary. It's not the end of the world.
Roger's extension to the "scope=" (or "s=") modifier covers all
the variants
but I'd prefer to see "s=*" for all scopes. Actually thinking
about it, "s=s"
for the "pra" scope is a little confusing, perhaps it ought to be "sc="?
We're not pressed for characters, so I'd vote for readability.
scope = "scope" "=" [ [ "-" ] scope-element *( "," scope-element ) ]
scope-element = ("mailfrom" / "helo" / "pra" / "ptr")
For a few extra characters, no one would be confused. Considering the
recursion depth of DNS queries, the extra characters are decimal dust in the
total overhead picture.
Now, MAIL FROM: can mean two different things: the actual return-path or
the SUBMITTER parameter. If it is SUBMITTER, then I would add another
scope-element "submitter". The reason is that we need access to the
return-path for some tests.
Also, without the scope modifier, the mechanisms should only
operate in the
"mail-from" & "helo" scopes for backward compatibility.
Not a bad idea, but which would it do? If by mail-from, you mean SUBMITTER,
they are the same, but otherwise they are not.
Also, harking back to a previous post, can the %{p} macro please
not return
the first domain, but the {responsible-domain} if present, otherwise the
first
domain?
I'd also like to see mandatory statements concerning the max # of
DNS queries
that can reasonably be performed to enforce a policy, so:
Infinite loop in include/redirect MUST return "unknown"
More than 10 DNS mechanisms per scope policy MUST return "unknown"
More than 10 redirected/included scope policies MUST return
"unknown"
How are these counted? If a scope has two scope-elements, does the
mechanism count as two?
(Not recursion depth)
(Total 100 scope mechanism tests - should be enough don't
you think?)
More than 30 seconds elapsed time MUST return "unknown"
I suggest total elapsed time should be user configurable.
--
Seth Goodman