[ietf-dkim] Issue: Requirements #9 NOT REQUIRED for 1st party valid
hsantos at santronics.com
Wed Aug 9 19:35:24 PDT 2006
----- Original Message -----
From: "Scott Kitterman" <ietf-dkim at kitterman.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
I would like to know if that's true.
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim