Alessandro Vesely wrote:
Ditto.
IETF standards convey the false impression that a matter has been
thoroughly analyzed and the protocols described are a definitive
solution. Actually, any establishment conveys that false impression.
And, today more than yesterday, there is a pervasive feeling that
exercising one's own judgment, initiative, and free will is not the best
option.
That DKIM deployment draft is avowedly pining for ideas. There is even a
figure where all arrows point to an "Identity Assessor". Yet, readers
may fail to consider it a call for such objects: piously self-assured
about IETF's soundness, they'll be at the mercy of the first one who'll
contrive something that can be sold by that name. (I've duped myself
like that several times, possibly in the hope to get the task done more
quickly than it would take to understand how to do it.)
Well, for me, it is very hard to continue "discussing DKIM" when it
fundamentally has a known engineering implementation conflict
(unauthorized remailer signatures not supporting ADSP) which not many
are interested in fixing. If that is part of what you mean as
"stranded" then I'm one of them. :)
Specifically the DKIM deployment guide has one section discussing
policy which addresses unauthorized signing threats and another
section regarding remailers that effectively ignores the threats that
policy attempts to address. Can't have it both ways. I specifically
ask to fix the semantics. DKIM supportive Remailers MUST NOT ignore
1st party policy. It is fundamentally inconsistent to have a protocol
designed to protect mail integrity and unauthorized signings, yet give
have an exemption for remailers.
See http://mipassoc.org/pipermail/ietf-dkim/2009q4/012648.html
--
Sincerely
Hector Santos
http://www.santronics.com