Scott Kitterman wrote:
I'm all for op=smime and op=pgp too. One thing at a time.
Okay. But let's keep in mind that adding some kind of weak
"anti-phishing" to v=spf1 with a dubious new modifier is odd,
if we could get the same (non-) functionality for stronger
signatures.
BTW, elsewhere you mentioned op=dkim as a way to overrule
SPF FAIL-results with DKIM. That's precisely how it cannot
work, all implementations supporting only SPF or ignoring
op=dkim would continue to reject SPF-FAIL.
You could define op=dkim to modify NEUTRAL, something like
"I always sign with DKIM, treat everything else like FAIL".
OTOH that's not very different from just using SPF + DKIM,
who would be interested in this op=dkim ? Just a selector,
"thanks for checking SPF, now you could also test DKIM" ?
The old meaning of "op" = "other protocols" as proposed by
Chris ? Some op=dkim.smime / op=dkim.pgp / op=smime / etc. ?
I've no problem with this approach, but it cries for a proper
IANA registry of "options", and so far I avoided the headache
of defining a registry. It would upset the IESG, registries
are _expensive_ (the review process for new entries, not the
resulting IANA file).
And if we propose the SPF Council as maintainer of the registry
we are in deep shit, the IETF would probably hate it, it's very
near to Chuck's "plan B".
Do what you like, but avoid new registries where possible. :-)