Hector Santos wrote:
----- Original Message -----
From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, August 18, 2006 4:07 PM
If that is what the OA domain (FROM) declares, sure.
Good. Glad we can have a shorter description.
But first he has to first declare he allows others to sign.
Why? To me, the above requirement makes sense even for
someone who is going to sign their own messages.
The proposed 3PS (3rd party signer) options are:
1 3PS NOT ALLOWED (what many of you guys did not want)
2 3PS ALLOWED NO RESTRICTIONS (what you guys want)
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. Whether a third party signature is present or not is
completely
irrelevant to the question of whether there is a valid first party
signature. And it's
totally bogus to impugn that people have somehow shifted positions
between now
and mailsig, and even if they did... so what?
Mike
3 3PS ALLOWED WITH RESTRICTIONS
4 3PS EXPECTED W/O RESTRICTIONS
The SSP-01 draft basically lacked the restrictions which nearly all the SSP
proponents agreed a delegation ideas was required since last year.
If by "you guys" you mean DAC, it would be nice if you didn't
put words in our mouths. To be specific, DAC hasn't made
any statements on SSP because there is nothing to make
statements on yet.
You should not make conclusions like this, but if the shoe fits...
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 personally never argued against a open-ended 3PS, but it does come with
high risk for exploitable, therefore it seems to me to be prudent to allow
the option for domains who wish have restrictive domain signing practices.
I see no technical reason not to allow for strong/restrictive policies.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html