Mark Delany wrote:
Given that the "slot in" to SPF hasn't occurred in two years
and SSP is likely to now expand in a dimension different from
SPF, maybe now is a good time to dispense with the syntactic
and cryptic comparability goal and do something that's a
little more human friendly.
If all you need from SPF are some modifiers feel free to use
it. The constraints are clear, a single SPF record is limited
in its size by UDP, "keep it short" is a necessity. But not
beyond recognition, some weeks ago Wayne posted something here
about the too terse SSP notation.
You can also reinvent the wheel wrt "some text in DNS" for SSP,
Phil had some interesting proposals how to do that better than
SPF did (avoiding "yet another DNS text RR" issues). Wayne had
another idea, "DNS text RRs for everybody". Somebody would
have to fight it out on namedroppers, please don't count me in.
At the moment I see a good way to get some kind of dkim=strong
or op=dkim accelerator in SPF indicating a STRONG DKIM SSP for
receivers supporting both SPF and DKIM.
If that would be all that SSP really does, either STRONG or
not, then reinventing the wheel might be a waste of time, just
specify it as SPF modifier and be done with it.
OTOH if DKIM somehow gets into a situation where supporting a
minimal part of SPF is "required" to get DKIM right it, then
we'd need "downref", the CLEAR-folks would be probably upset,
and I'd really prefer it if DKIM makes sense without SPF, and
vice versa. The fine print "DKIM is strong where SPF is weak,
SPF is strong where DKIM is weak" should be obvious without
spelling it out in the form of any normative reference. Bye
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html