Mark Delany wrote:
It's more about whether SSP should be constrained to a
byzantine syntax to encourage convergence.
| name "=" macro-string
Rather harmless, any visible character except from "%", and
to get a literal "%" you'd say "%%". The byzantine part is
limited to anything else starting with "%".
the fit is a strain.
Yes. Talk about less than 100 characters, and I'd say "go",
if you want much more better stay away from SPF modifiers.
most of SPF is about (resolution) mechanism, not policy.
Whereas all of SSP is about policy, not mechanism.
In SPF terminology mechanisms are also "policy". Different
ways to enumerate all IPs combined with "pass", "dunno", "fail"
qualifiers. For some ways your "byzantine" and my "baroque"
might be identical... :-)
Furthermore, all indications are that folk here have plans
for much richer policy - such as "Check my reputation here"
or "I'm accredited there" and that seems not to be on the
SPF radar.
"We" (SPF) had the same discussions, folks inventing wild and
wonderful new modifiers, but nothing got real traction. Phil,
William, and I went so far to put something into I-D format.
But if no implementor makes noises to support any of these
ideas it's pointless.
Whatever you do, don't try any "XML over DNS". Just don't.
Finally, history suggests that SPF isn't much interested
in convergence with DKIM.
Not sure what you're talking about. SES ? Meta ? SPF is
very strict about its focus on 2821, and DKIM is apparently
strict about its focus on 2822. That could be a fit as far
as I'm concerned.
SenderID is of course a different matter. Like STRONG DKIM
also addressing "phishing", and using 2822. Unless you have
ideas for the first "positional modifier" it's the same SPF
syntax, otherwise it's minimally more byzantine than v=spf1.
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"
Okay, for anything that's more interesting than YES or NO the
best way to get around size issues. The byzantine "exp" is
a better example for that purpose, "redirect" is too special.
rather than try and constrain ourselves to SPF syntax and
hope they adopt and embed it.
The "they" would be implementors, SPF or SSP isn't the point.
You're perfectly free to publish drafts with new SPF modifiers
if that's the most simple solution for a problem you want to
solve. If it gets out of hand we'd need a proper IANA registry
for modifiers, but that's only a formality.
If an implementor would tell me that he really likes op=auth
(for reputation) or op=pra I could submit the draft within an
hour, it's ready. That didn't happen for more than a year.
And op=pra could make perfect sense in the situation as it is,
telling the same story twice (in spf2.0/pra,mfrom and v=spf1)
is stupid wrt UDP size issues, one "v=spf1 op=pra" is shorter.
To redirect and decode SSP is just another variant.
True, but it would only work for systems supporting SPF and
DKIM. For systems supporting only DKIM you need some well
known place in DNS derived from a domain relevant for DKIM -
that's probably not what you find in the MAIL FROM. Maybe
the HELO is more interesting wrt reputation.
If that's supposed to work for systems only supporting DKIM
but not SPF, then a simple flag in the sender policy instead
of a redirection could be good enough:
yes: it makes sense to query well known DKIM place for more
no : don't bother to query, I don't support this DKIK stuff
The dkim=strong idea is similar, "don't bother to check SSP
for _this_ domain, it has a STRONG DKIM signing policy".
Bye, Frank
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html