Steve Atkins wrote:
On Dec 7, 2007, at 10:52 AM, Michael Thomas wrote:
Steve Atkins wrote:
On Dec 7, 2007, at 10:17 AM, Michael Thomas wrote:
It sure isn't obvious to me, and I'm afraid that I'm at the end
of the road here as I can't figure out what set of axioms that either
you or Dave are operating from for that not be true. From the looks
of it, that set of axioms leads to "SSP == bad", so I again wonder
why you're wasting your time, unless it is to prevent SSP from being
published.
I like DKIM.
Publishing a bad (harmful or overly complex or with no actual benefit
or...) protocol tied closely to DKIM would be bad for DKIM
deployment.
Steve,
Are you comfortable with a DKIM only world, if not, what should be
augmented with it to secure some basic exploitations?
Or
Are you comfortable with a DKIM only world with verifiers only treating
valid signatures "more special" than the rest, including a verifier
seeing a domain with all three types of messages coming in, treating
these less special?
NO signature
Valid Signature
Invalid Signature
Which ones are more important?
What I am pointing out is that, forget SSP, forget everything else but
consider only DKIM, why should a verifier go to the trouble and cost of
development to process DKIM messages when its only interested in the
valid ones and ignoring the rest?
How is the domain protected with is new DKIM signer responsibility?
He is only responsible for the mail he does signs and not responsible
for his domain mail he intentionally decides not to sign?
My point in all these question is that there has to be some technical
protocol consistency in all this. Forget SSP, use something else, who
cares! I have a hard time believing Verifiers are just going to look
for the valid needle in the haystack while ignore all the other
potential thorns.
Of course, we have a problem with mail integrity mishaps.
But it doesn't really make sense for verifiers to just accept or treat
more special the valid signature and leave them in limbo with the same
domains being exploited with fake signatures or just DKIM ignorant
legacy bad guys spoofing with non-signed messages.
So in one respect, I really don't care what technology XYZ is, we need
something to help protect against DKIM fallacies.
In the other respect, SSP is as good as it gets, in my opinion, as a
open public protocol which interfaces quite well with the possible DKIM
signer results.
DKIM risk falling into a "batteries not included" dilemma that many
other early rudimentary technologies have suffered.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html