Just note to start with that current SSP syntax is not really compatible
with SPF on the protocol level. It just uses some of the same symbols that
have special meaning in SPF, but the way they are used (policy=symbol) is
very different then spf where symbol is prefix for mechanisms. The
"policy=symbol" is ok with SPF as a modifier but modifiers are not treated
same way as mechanisms and need not use any kind of special symbol (so for
example for meta signatures which is using SPF as policy record, the
modifier has text as a value i.e. "metasig.sender=required").
On Fri, 17 Feb 2006, Mark Delany wrote:
On Fri, Feb 17, 2006 at 05:28:04AM +0100, Frank Ellermann allegedly wrote:
You can also reinvent the wheel wrt "some text in DNS" for SSP,
No, that wheel has long existed. It's more about whether SSP should be
constrained to a byzantine syntax to encourage convergence.
Even in the most positive of circumstances the fit is a strain. After
all, most of SPF is about (resolution) mechanism, not policy. Whereas
all of SSP is about policy, not mechanism.
Furthermore, all indications are that folk here have plans for much
richer policy - such as "Check my reputation here"
"Check my reputation here" is not appropriate policy. Anything the
sender says including where to look is accreditation info.
or "I'm accredited there" and that seems not to be on the SPF radar.
I do not see it happening for crypto either if systems check SSP only in
case signature does not match address in From field.
On the other hand SPF is checked for every message and it as well suited
to accreditation info with SPF modifiers as as SSP is - the syntax is also
likely to be the same (spf modifiers are basically freeform name=value data).
Finally, history suggests that SPF isn't much interested in
convergence with DKIM.
The simple solution is to develop SSP as we see fit and, if at some
later stage it gets acknowledge by something like SPF, then SPF should
simply point to SSP along the lines of "redirect" rather than try and
constrain ourselves to SPF syntax and hope they adopt and embed it.
I don't expect that to be a burden for SPF - after all, they already
have syntax and logic to redirect and decode A records, redirect and
decode MX records, etc. To redirect and decode SSP is just another
variant.
It would require new version of SPF for it to understand some new type
of record, nor do I see redirect ever being used in the way you suggest.
(and it does seem that you're not well versed in how SPF works based on
how you describe it above).
Now as far as SPF use of crypto signature data, assuming the signature
is based on the identity address that is found in Envelope From that
could be of use. But in that case the SPF record would be the one to
provide policy information about its use anyway not some other record
as SSP by current drafts is for use with From header field.
My suggestion however (just in case) is to have "scope" included in SSP
as part of its syntax - so it could be used for other things and without
the kind of problems SPF has experienced because of old decision to not
include scope in late 2003 drafts that sparked active development.
BTW - If you do want to have certain compatibilities with SPF than all
you really need to do is keep "name=value" tag system (and also include
v=?? as prefix).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html