> John Levine wrote:
>> FYI, that section is taken verbatim from the MLM draft that Barry sent
>> off yesterday. I guess now we know who read it and who didn't.
> Dave CROCKER followed up:
>
> He was just following instructions:
>
> On 5/11/2011 10:36 AM, John R. Levine wrote:
> > ... but you should blame me for
> > the whole thing, borrowed or otherwise.
>
> d/
For the record, the old MLM was read as well Levine's poison pill MLM.
With no intent nor suggest the writer is stupid, writers do say stupid
things and that paragraph was "stupid" then and it remains to be
"stupid" as in a stupid manner; "he had stupidly defined a one way
ticket for DKIM."
I have noted the issue before but I guess it didn't get any attention
until it was called "stupid" - very funny.
That said, FWIW, I do apologize it was given that attribute and I am
sorry it was read with an ill-intent in mind. Everyone here are
pretty smart and experience people. It would be "stupid" to think
otherwise. We simply have different views, and unfortunate strong
views residing at point ends of the spectrum.
In strong opinion, even I would accept the single output modeling, you
can't have a background description that says X is the only way, then
have deviations of that X in the document and in other documents.
I tried to suggest how make it both functionally and technically
correct with the general statement that:
"X (DKIM) under Y (MLM) conditions can only work one way (RESIGN)
by assigning Y trust when Z (Author Domain) has no policy against
it."
We are talking a special stream (MLM) that historically and inherently
breaks the integrity of mail (in an industry acceptable manner). DKIM
does not naturally fit into the MLM technology and thus the feasible
"Pottery Theorem" solution is correct - resign.
But I object to the idea it is an unrestricted resigning model only
and I firmly believe it will harm the general wide best interest of
the IETF mail community and DKIM itself if we allowed this to be the
one way ticket.
Is that any more clear?
--
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
