ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

2006-08-21 07:48:29
It sounds like what you and few other people want is an SSP policy
that says "if you receive a message that is supposedly from this site
(for some definition of "from") and it doesn't have the mark that
says that XYZ is authorized to sign the message, assume the message
is forged". Is that a correct summary of the requirement you see?


I am glad you put a question mark at the end.

It took me a while to read through this can of worms, but for every
argument against the optional flags that myself, Hector, and I few
others are looking for, I see contrary arguments that only bolster the
point that these thing we are hinging on are OPTIONAL. Just because
they are OPTIONAL does not automatically make them irrelevant nor
unnecessary. I have yet to see an argument that shows where they are
technically unsound in everything but statistically insignificant
situations, which in my opinion is the litmus test for dismissal.
I really did not want to see this turned into an 'us' against "ya'll"
discussion. (ya'll _is_ a word in Georgia) But arguing against
something that a) Is technically sound b) Would benefit many entities
c) is OPTIONAL, to me, sounds like ya'll are being contrary just to be
contrary. And if the 'Ya'll' shoe fits... please don't take this as a
personal attack. I have always been impressed with the amount of
intelligence in this group and I consider each and every person in it
my friend and colleague.

I can't name many people in this group that are less eloquent than I,
so I have chosen a few points to high lite. Also, it seems to me that
people are not really reading what Hector is taking a lot of time and
thought in putting forth. While I may not always agree with approach,
I mirror his technical points. Hector and I have not always seen eye
to eye in technical discussions in the past, but I believe (and have
experienced) that both of us submit to better arguments. I notice that
neither of us is budging on this point.

-Hector Santos-
But we also want the option to control the potential abuse this open-ended
3rd party signing can caused as it been shown can and will happen.

The SSP people provide all the OPTIONS, the relaxed and the strong, the
restricted and unrestricted, including the relaxed to no-policy concept you
guys seem to want.

By "You guys" I meant those who have shown to be nearly 100%consistently
opposed or resistant to any kind of 3rd party signature restrictions which
has been the numero uno basis division going back to MAILSIG.

I see no technical reason not to allow for strong/restrictive policies.

-Michael Thomas-

I wish you'd stop putting words into people's mouths. There is a major
disconnect between your understanding of what is needed and as far as I can tell
just about everybody else's.

-- I am baffled by the above statement.

-Hector Santos-

The fact is you have not being trying very hard to "tell" because there are
clearly people here who have expressed repeatedly the benefits of allowing
restrictive 3rd party policies, if so desired by the domain.

That's the kicker here, its all OPTIONAL yet, you are not even open to
making it an option.

So who is more open-minded here?

-- I could not have said this better myself... hence the cut and paste.


Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>