Scott Kitterman wrote:
OTOH, when was the last time we seriously discussed
op= anything.
About once per month, we had dk, pra, rfc822, auth, helo,
trusted, and similar ideas with different names. Last
that I vaguely recall was Julian proposing op=pra with a
different name in the -02pre phase.
It is not nice from a readability perspective.
It's not worse than CIDRs or Greg's include:not.me trick.
As always we disagree about SPF's ability of being nice
to publishers. I want SPF as a lethal weapon, shoot on
sight, and if its your own foot so be it. You want it
to never hurt legit senders.
Readability is nice to have. Don't waste precious bytes
is also important for some policies. And if some of the
technical issues are identical for yes/no-modifiers, why
not solve them once and be done with it ?
Being nice to implementors and more important receivers
is the trick, they do something four "us" (publishers),
there must be an incentive to check SPF from their POV.
record size isn't a major issue
That's not my summary of some threads started by Radu.
I think it can't be a zoo, because these new modifiers
are limited to things that don't change the SPF result
because current implementations will ignore them and
future ones are free to.
Yes, and that's explicitly stated in the op= memo. It's
not exactly obvious in the SPF RfC.
There just aren't so many things that are worth putting
in an SPF record that won't affect the SPF result.
We've discussed quite a lot of ideas (not only "options",
also stuff like accredit=, eh=, etc.). But if you see a
question like "what's the value of from=, there must be
a value", and the best answer is "yes on both accounts",
then it's a case for op=.
At least the common issues are then clear, and you're not
wasting time with "yes" vs. "1", and what about "no", "0",
"-1", or "2". Reinventing the wheel.
Any from=yes invites questions about from=no, even if you'd
say that it's forbidden. Some users would publish obscure
from=no nsense, others from=1, broken from-implementations
would interpret any from= as from=yes, even from=no, others
would forget to handle mixed case from=YeS, etc. ad nauseam.
for those with long records they can split them into
subdomains and deal with it.
Not nice to receivers. As publisher of texts you care more
about your audience. A split policy needs more queries,
for each and every tested MAIL FROM. Especially for FAILs
caused by -all at the end.
We can probably argue about this for a while now.
Yeah, do we want a framework for options, or is it a waste
of time, because so far all options (modulo pra) turned out
to be more or less irrelevant statements trying to dictate
receiver policy ? Or their value was esoteric - I could
explain what "your" op=auth is supposed to do, but I don't
expect that a reputation service gets the idea, and that's
the only interested party in this case.
But if we'd find a really useful option, or if I'd decide
to publish op=pra for mainly political reasons, then using
this obscure "option framework" instead of repeating old
yes/no-debates makes sense.
Bye, Frank