Sean Shen wrote:
Hi, Dave,
I have a question when reading the 01 version.
In section 14
" Corrected Text: Once the signature has been verified, that
information MUST be conveyed to the Identity Assessor (such as an
explicit allow/whitelist and reputation system) and/or to the end
user. "
I don't understand why use "and/or" here. Will eventually be an "and" or an
"or"? Using both is confusing expecially when there is a "MUST" in this
sentense.
I notice "and/or" is also in 00 version, maybe there were discussions on
this point before in the list but I missed, it so, please point me to it.
BR
Good point. Thank you for highlighting this.
More critical is why is there an enforcement at all, a MUST, to convey
anything to anyone?
My pet peeve with how DKIM has been introduced, even though
"reputation" was suppose to be out of scope (wink wink), the key cogs
ignored that fact and still continued with a subjective "Batteries
Required" idea, an under and undefined non-standard layer regardless
of the fact there was a significant group who were against this.
I don't plan to display a "Gold Seal" to users, changing our
presentations for a # of reason. I have no control over how the final
storage will be done. Once email is transported, the final deposition
can be a converted, gateway or transformed storage for the end user,
all depending the installed operation. We have many operations who
use the conversion as a security measure to protect used from email
exploits.
Our initial #1 goal with DKIM is to use it as a filtering process -
dissemination of the bad vs the good during the transport process.
Once a signature is verified, nothing else is going to be assumed
about the trust value of the message. It just passed another "test."
Now, if some solid standard reputation system (and I mean standard),
then something can be explored and argumented in the future. It was my
sincere hope that the policy considerations for the past three years
with SSP and post-modem SSP (aka ADSP) would assist in this matter as
another layer to help filter the bad vs the good.
I am not suggesting that other implementations should not do what is
written to "MUST convey" this information. Thats their judgment. But I
don't like the idea that it it been enforced when in fact, Reputation
was suppose to be out of scope. If it was a solid concept, no sweat.
But it is far from it, and the last thing I want to do is to display
erroneous information or false illusions of trust or errors with From:
vs I= discrepancies issues during presentations, in additional I will
really hate to be telling customers "DKIM requires extra Batteries" in
order to work. Until this is rock solid and completely worked out,
this simply increases product liability issues.
My opinion of course.
--
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