wayne wrote:
I don't see the problem with adding the scope= keyword
Then let me help you to see the issue:
scope=helo => helo world, first we take CSV...
scope=mfrom => ...then we take MARID and spf2.0/mfrom...
scope=name => ...and then we are game for a scope=PRA
One parameter, and you alienate the CSV-folks while there's
just some peace between "them" and "us" enforced by Bruce, and
you also give Ted fresh ammo for his "v=spf1 is MARID is PRA"
fantasy.
The optional scope= information on the Received-SPF header
does not change the semantics of SPFv1.
Yes. and it's also unnecessary for v=spf1. It works how long
now, 16 months, more (?) without a scope=mfrom. IIRC the term
"mfrom" was an spf2.0 term invented in August 2004.
If you want to invent a new parameter why not something like
checked "identity" with a value of...
identity = [ local-part "@" ] domain
2822-terms, no unescaped semicolon, good enough. If it "must"
be what you have try s/scope/identity/ and s/mfrom/mailfrom/
Everywhere in the spec. you say "identity", HELO or MAIL FROM,
no good reason to switch to "scope" and "mfrom" here. Unless
you _want_ to alienate folks, starting with me.
I do not see how adding information to the Recevied-SPF
header restricts future solutions to the overall problems
with scope definitions.
Because "scope" has the bad smell of 2822 and "united". Just
looking in -01 I see 'if no mechanism matched, substitute the
word "default"'. Is that about the default ?all for a policy
without any all ?
Don't waste too much time with new Received-SPF features, if
Kucherawy gets it right there might be soon something better
not limited to SPF.
Bye, Frank