-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Scott Kitterman wrote:
Maybe the guidance is the MSA operator publishes it in their SPF record
that their customers include:. Then it's the MSA operator making the
declaration.
I think that works as expected only after a redirect. RFC 4408 explains
this for exp= modifiers, an "included explanation" is not visible in the
including record.
Scott raised a very important point. Each modifier, or in the op= case,
each op= option, should explicitly(!) specify its scope, i.e. where it
applies. A reasonable generic default scope would probably be "the entire
policy record that contains the modifier or option, but not superordinate
records and not subordinate records".
Furthermore, why can the op= modifier not be positional? It doesn't really
matter whether RFC 4408 defines only global modifiers. (Actually, RFC
4408, section 6 mostly talks only about "these two modifiers [defined in
this document]".)
draft-ellermann-spf-options can very well, and should, define op= as a
positional modifier, and op= should of course be allowed to occur more
than once in a record. Whether each option is global or positional in
itself should be defined by that option.
For that matter, op=(no)auth should be positional.
The include: mechanism maps an included PASS (hard or soft) to a match,
and then the including policy maps that to whatever it wishes, e.g. FAIL
for include-not-me cases, NEUTRAL for an unreliable ISP, or a PASS.
The latter is what we're talking about, but it's an ordinary "soft" PASS
at this point, the including record needs its own op=auth to declare that
it's a "hard" PASS.
Agreed. op=auth must not leak back into superordinate (including) records.
op=auth applies only to "Pass"es invoked from the same record where it is
set -- possibly only to mechanisms that follow the op=auth, up to the next
op=noauth (if any).
I wonder, however, if op=auth (positional or not) should cover
_sub_ordinate (included) records? If yes: what if the subordinate record
says "op=noauth"?
If somebody will write the code to test it, I'll put it in my MSA
records.
[...] Testing the op= syntax is possible. Implementations could offer
augmented result codes (with HARDPASS), that could be tested.
(I just updated my records.) Augmented result codes are exactly what I'm
doing with Mail::SPF. A result can include a set of flags (derived from
options or other circumstances) and other meta-data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFEnjUwL7PKlBZWjsRAuZRAKCQ4wPDKhP9xBxFQFdCB2A5HoOHbgCg8F9e
/5KRj+GAlsyH2ImDjk1heBg=
=XeRQ
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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