On 8/9/06, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
----- Original Message -----
From: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
> Here is a concrete proposal....
>
> In this round, we only specify sender policy for 2822.From.
> To the extent we have consensus that SSP is a good thing, we
> have consensus that it should cover 2822.From. Once you get
> beyond that, consensus is elusive at best.
>
> There is a requirement that the protocol be extensible.
> Later, if there is a demand, something else could be added.
As shown in the pseudo-code posted in my last message, I believe the
original thinking was basically only do to a 2822.From policy lookup when
there was a 3rd party domain signature binding.
hmmmm, in fact, re-reading requirement #9, the mentality might still reflect
this original thinking:
The Protocol MUST NOT be required to be invoked if a
valid first party signatures is found.
I ask for the author's confirmation or clarification on this.
Since day one, I had some concerns with this logic as it revealed some
issues regarding other possible domain Practices possible and as well as
exploitations possible. Hence the reason for the Policy vs. Verification
tables, showing why the SSP should always be done on the 2822.From and the
beginnings of the DSAP drafts to document the reasons, method to resolve
this, and illustrating a reliable verification chart.
Also, I think by introducing 2822.Sender: this will inevitably begin to
touch base with 2821.MailFrom considerations as well and I think that will
take up into a new level of 2821 vs. 2822 issues and debates, or something
think you guys call a "Rat Hole?" <g>
I'm not saying it is bad idea. I am just saying I think it might
force some other considerations as well for which if we want to do this, it
might probably be worth the effort.
So maybe if we can easily construct this to be able to add Sender: as an
extended implementation option without breaking the minimum requirements, I
would put my +1 to this.
But it now seems, that requirement #9 might actually reflect the original
logic intended.
I would like to know if that's true.
Maybe #9 is an incomplete statement?
The Protocol MUST NOT be required to be invoked if a valid first party
signature (without the 's') is found. However, if the first party
signature if damaged in transit the Protocol MUST be invoked to
determine if any authorized domain or third party signers have signed
the message. The order in which each authorized domain or third party
signer is validated MUST NOT be specified.
Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html