----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
Well, first, we're still focusing on the base, which is supposed to be
done within two months now.
And you think there is nothing to be learned from SSP or not engineering
feedback that can help better mold the final base product?
Second, even SSP does not aim to address the quality of the message or
the trustworthiness of the signer.
Well, first, It might have been more appropriate to say Quality of the
Transaction instead.
Second, there are many levels of trust. They one I believe you are
referring to is the Accreditation/Reputation concept.
But the other form of trust is established in the system's protocol
consistency. It is a deterministic concept. Not heuristic. That is what
SSP offers. It helps police the transaction. It helps keep that "quality"
consistent. It helps promote transaction survival. It helps make systems
work together better, and surely much better than a DKIM-only concept where
you currently have all this ambiquious questions and debates.
Have you found the time to understand the easy to follow DKIM/SSP logic
illustrated in:
http://www.winserver.com/public/ssp/ssp.htm
The closest it comes to that is that
in the current formulation, the RFC822 From domain can advise the
recipient that it would like them to be suspicious of messages that are
not signed directly by it.
You see, you say "advise." I say "mandate, expose, dictate, define,
establish" a level of expectation in the formulation of the transaction.
That is not to suggest that the verifier will actually follow it, but that
it is a strong "standard" or BCP on expected behavior. That is the basis
and framework of telecommunications. If protocol is not follow, then you
have failures and if you don't address these failures, then you will have
exploitations and all kinds of chaotic situations yet to be fully realized
but quite of bit of predictable chaos. I will venture to say if unchecked
failure outweight the good, than DKIM has failed in its purpose.
Fuzzy concepts that include semantics like "advise" is only appriopriate
where there is a no necessity to apply any other controls. This is clearly
not one of them. It is akin to the same issues that begat EHLO and MAIL
FROM. No mandate to follow protocol consistency and we ended up with a
multi-billion industry wide costly suite of email security issues. We are
repeating history with this unchecked DKIM-only concept.
So what are really talking about here? The unsureness of middle ware, of
what could happen between two endpoints?
This begs the question, is DKIM appropriate for Mailing List systems? It is
clearly not today. Yet, one school is attempt to mold and detect "design
changes" to follow your "definitions." Well, I as a seasoned engineer and
author too of SMTP and List Server software and I don't see any common sense
in the current suggestions. I see more harm than good. I am wrong, please
sure how DKIM is safe without SSP. Please sure how you can in a much
clearer and clean matter resolve all these questions without SSP.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html