Julian Mehnle wrote:
how is "op=2822from" any better than "addl-scopes=2822from"?
Or, how is "op=2822from.pra" any better than
"addl-scopes=2822from,pra"? (Except for being slightly
shorter.)
Shorter is one of the reasons. Trying to summarize several
hundreds if not more of articles here is a second reason.
Explaining what's wrong with a remove-scope=pra is a third
reason. Plus other CAVEATs about interpreting the absence
of new "optional properties", or why the presence of a new
"optional property" in a sender policy might have no effect.
[...]
2. Motivation
The SPF community often discusses optional "yes", "no", or similar
modifiers. SPF allows the introduction of new modifiers without a
new SPF version under two conditions:
1. All SPF implementations can safely ignore the new modifier.
2. Implementations supporting the new modifier interpret all
policies without this modifier like all other implementations.
The op modifier is a shorthand for optional properties and "opt-in"
procedures. The length of SPF policies is limited. Instead of
separate modifiers as in...
IN SPF "v=spf1 o1=yes p2=no q3=1"
...the op modifier allows the shorter notation...
IN SPF "v=spf1 op=o1.nop2.q3"
...for hypothetical properties o1, nop2, and q3. Please note that a
policy without one of these properties does not implicitly have any
"opposite" property. Existing sender policies and implementations
may not know these properties. They are also free to ignore known
properties intentionally.
It is possible to define a hypothetical property p2 as the opposite
of nop2, and to specify it explicitly in a sender policy. The
definitions could state that p2 and nop2 must not be used together.
3. op: options
The op modifier introduces a dot-separated list of optional
properties. New properties can be defined in additional documents in
the same way as new SPF modifiers.
Classic SPF modifiers are always global, they affect the complete
sender policy. At most one op modifier is allowed in a SPF sender
policy. It's a good idea to specify an op modifier before the first
directive. An ABNF specification for options:
options = "op=" name *( "." name )
Property names can be given in any order, it's no syntax error to
specify the same property more than once. The term name for
individual properties is defined in [I-D.schlitt-spf-classic].
[...]
[... (3.1 nohelo) ...]
[... (3.2 helo) ...]
[definitely "related"]
[...]
4. Security Considerations
Please consult the security considerations in [RFC2476] and
[I-D.schlitt-spf-classic]. A sender policy is only a claim by the
domain owner, this can be a spammer or an attacker.
[...]
5. Document History
The versions 01, 02, and 03 of this memo were written in the style of
a possible chapter 6.3 in [I-D.schlitt-spf-classic]. The versions 02
and 03 explicitly stated that this will never happen.
Version 02 renamed the 01 properties, "helo" was "hector", "trusted"
was "meng", "rfc822" was "william", and "auth" was "scott". The
original ideas for these properties were posted and discussed on the
SPF-Discuss mailing list by various authors.
Version 03 dropped the properties "pra" and "rfc822". Nobody was
interested to emulate the effect of a "spf2.0/mfrom,pra" policy with
a "v=spf1 op=pra" construct.
Version 04 dropped the property "nosub" added in version 03. It
could be used in an alternative to the zone cut algorithm removing
domain labels left to right until a sender policy without "nosub"
property is found. It was the opposite idea of the now long dead
"match_subdomains=yes". The next SPF draft will remove the zone cut
algorithm, therefore it's pointless to support an alternative
algorithm.
[...]