On Jan 15, 2008, at 4:01 AM, Charles Lindsey wrote:
On Mon, 14 Jan 2008 17:33:37 -0000, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
Your reading of the archive shows rather more complete and
definitive discussion than mine. In fact I read the archive as
tending in the direction of changing the specification to use
Sender: rather than From.
Would you please explain the basis for assessing that this topic
got sufficient discussion and that there was rough consensus on it?
Since this specification modifies RFC2822 that fact needs explicit
justification.
The current SSP language modifies RFC2822, and so there should be
considerable clarity about the need, the benefit, and the impact.
Indeed. I don't like that "1st author" bit.
At least this limits the expected number of transactions for obtaining
the SSP policy. : )
If there are multiple authors, then whichever one is also the Sender
should be the one that the signature should relate to.
Agreed. The signature should accurately reflect which entity the
signature is on-behalf-of.
If the Sender is none of them (the secretary sent it on behalf of
them all), then there is a problem. In that case I might be happy
for the Sender to match the signature, or even to go back to a
"first author", though I don't really see what is wrong with an "at
least one author".
There is not a problem when signatures are permitted to be on-behalf-
of any header or entity with a proviso that the signature's domain
would have been valid when used for the "first author". The only case
where this might be a problem would be when g= restricted keys are
used to sign on-behalf-of entities that are not "first authors". The
easiest solution would be to declare signatures not on-behalf-of
"first authors" having restricted keys to be considered "invalid" for
the purpose of SSP compliance evaluation.
It the Sender is absent with multiple authors, then the message if
not RFC 2822 compliant, and all bets are off.
Dave was right to suggest only considering the domain of the
signature. This problem is greatly simplified by only considering the
domain of the signature to be significant.
And if the signature is "restricted" (by g= or whatever), then the
rules might be different.
Agreed. A restricted key is the _only_ case where a domain's signing
policy might not have permitted restricted key's use for entities that
are not "first authors".
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html