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.
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.
If somebody will write the code to test it, I'll put it in my
MSA records.
It has no defined technical effect for receivers, hard to test
it... :-) Testing the op= syntax is possible. Implementations
could offer augmented result codes (with HARDPASS), that could
be tested.
Frank
-------
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