Murray S. Kucherawy wrote:
-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)isdg(_dot_)net]
Sent: Monday, August 30, 2010 1:00 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Proposed changes to MLM draft
I truly hope your are not force to split your document that minimizes
the need for Mailing List Software developers to correctly engineer
their products without producing erroneous DKIM signatures problems
for members.
I don't see how the proposed document split minimizes anything.
There's a legitimate question of whether or not we should try to
compel MLM developers to write their code to preserve author
signatures. We can debate that question, but if in the end consensus
says it's not a useful goal then we shouldn't bother producing text
that says it is.
That's a separate issue from the list signing traffic that goes
through it irrespective of author signatures.
Once again, the real issue is being pushed and brushed aside regarding
the developed WG product products:
RFC 4686 - Analysis of Threats Motivating DKIM
RFC 5016 - Requirements for DKIM Signing Practices Protocol
RFC 5617 - ADSP
which 100% relates to the "Question, Debate" to the issues regarding
signature violations, breaking them and/or preservation.
So what are we really debating? Should MLM or any DKIM verifier
ignore theses in the interest of preserving something that is 100%
known to be fault or violation?
We need to get to the heart of the issue here because its been the
same conflict for too long. If POLICY is part of the picture, MLM has
no choice to support this portion of the DKIM protocol engineering -
otherwise you have "bugs," incompatibility issues and possible
accusations of reputation harm by intentional ignoring a IETF produced
standard that exist 100% design to address this signature violation
issues.
The only way to remove these BUGS is to get of out the POLICY related
WG work products.
IMO, while policy is still part of the picture, your MLM draft touches
base with all the issues. No split is required.
--
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