Doug,
You are repeating yourself, yet again. As far as I can see
all this was raised by you before and none of it achieved
WG consensus.
Feel free to try convince Barry and I otherwise, *off-list*,
but please do not continue to try to reopen closed issues
on the list.
I see all this as being covered by issues 1265, 1272 (raised
by you and accepted), 1274, 1285, 1288 and probably others
(I got bored in the issue tracker). I see no WG consensus to
re-open those issues.
Stephen.
PS: I repeat, please feel free to convince us that there's
something new here, but not on the list.
Douglas Otis wrote:
On Jan 4, 2007, at 6:28 AM, Hallam-Baker, Phillip wrote:
That is a meta-argument.
At this point we have a last-call objection to close. 'We decided
differently' is not a valid move in a last call discussion.
If the point was argued and consensus reached there should be someone
who can give a rationale for MUST NOT as opposed to SHOULD NOT.
The problem stems from a mandate to sign specific headers or require
that domains match within the 'i=' identity. Protection is established
by an association between the signing domain and an originating entity
digitally "recognized" by the recipient. The mistake within the base
draft stems from an erroneous predetermination of which headers are to
be signed and removal of an ability to link headers containing different
domains. "Repairs" can not rely upon a signer making copies and thereby
ignore recipient recognitions, (the purpose of using different headers
or perhaps even "downgrading" headers).
The underlying premise used by the base draft is fundamentally flawed.
There is little if any protection afforded by a visual recognition
process anyway. The recognition process must be based upon information
held by the recipient. This approach means protection is afforded by
actions of the MUA or MDA. This could exclude a transit MTA, unless
protection identifies phishing attempts by comparing message content
against known valid signing domains. Even that protection depends upon
a type of recognition not covered by any header, nor should this be
limited to specific domain matches either.
The base draft contains fundamental flaws with respect to a protection
strategy. Reconsider how protection can be afforded and how private key
sharing or zone delegation can be voided (an expensive prerequisite that
also removes normal freedoms).
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html