Frank Ellermann wrote:
I don't understand the DKIM proposal, why would you look up
DKIM for the most important SSP case "no signature" ?
You are also thinking optimization, which is good. :-)
Well, did you notice there is no such direct definition for SSP "no
signature"?
I don't understand why you keep injecting SPF here
Wait a moment, adding SSP info to DKIM was *your* proposal, and
that made no sense for me.
Well trying to understand it first should be a prerequisite. :-)
I'm
not hot about SSP-accelerators in SPF, as Jim said it's likely
too early to discuss optimizations.
We were talking about about SPF or SSP-accelerators in SPF.
Read his entire response again. He provided various views including one
that that agrees with the proposal benefits. Once the holidays are
over, I will raise/discuss the two new issues again.
Personally, the genera idea that when something is considered an
"optimization" therefore it should be pushed aside as an implementation
or deployment issue isn't always automatic or cut and dry. Especially
when the current deployment draft has little to no regards for SSP and
itself also changes the semantics of DKIM signatures.
So while one might want to dismiss it as a "optimization," in my
engineering opinion, DKIM/SSP are tied at the hip. It is what the SSP
proposal needs to address the lingering DNS concerns and possible
security effects. In fact, just look at what the SSP draft TO BE DONE
section says:
(Unresolved Issues/To Be Done)
Need to consider handling of multiple responses to a DNS query for
the SSP record.
So one can't have it both ways.
SSP as a proposal, at this point needs to maximize its adoptability
effectiveness and that includes "selling" how it improves the DKIM-BASE
system.
1) if SSP helps make DKIM-BASE "work better" and it helps resolves
DNS caching and NXDOMAIN issues or concerns by having a
default record, then that should be part of specification.
2) For those DKIM people who always wanted restrictive and nothing
but restrictive mail handling should be able to do so
without confusing others or creating more DNS related issues.
RFC includes recommendations that are both normative and non-normative.
There is no reason to brush aside non-normative information when it
helps "sell" the product better. SSP is fundamentally about the
maximization for the efficacy of the DKIM-BASE protocol. Thats its
purpose and optimization is a fundamental part of the process.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html