On Jan 16, 2008, at 12:13 PM, Jim Fenton wrote:
The roles of sender and author are different. The fact that a
Sender header field is required when there are multiple authors is
not an assertion that the sender is, in fact, an author. It's
merely a consequence of the fact that the sender (agent responsible
for the actual transmission of the message) cannot be inferred from
the From header field in this case.
SSP seeks to determine the author's policy.
SSP asserts the policy of "first author's" _domain_. It is not
accurate to describe SSP as the "first author's" policy. Nothing
within SSP offers this level of policy granularity.
There is no need for a signature to always be on-behalf-of any
specific header of the message to be compliant with "all" or
"strict". Efforts at restricting the i= parameter are doomed by the
complexity. Referencing policy should be limited to the "first
author", otherwise validating a dearth of unsigned email is doomed by
overhead.
Provided the _domain_ of the signature is able to have signed for the
"first author", a message can be defined as compliant with "strict" or
"all" assertions when signed by an unrestricted key on-behalf-of _any_
identity.
Specifically signing for the "first author" is _not_ required. DKIM
or SSP is not about assuring the identity of the "first author", or
providing "first author" specific policies. Compliance is determined
by whether the originating _domain_ of the message is compliant with
the "first author's" _domain's_ assertions.
Whenever a message does not contain an unrestricted signature applied
by the _domain_ of the "first author", SSP needs to be checked. An
exception should be made for restricted keys. Restricted keys should
only be compliant when on-behalf-of the "first author".
By not restricting the i= parameter, DKIM is able to clarify which
entity introduced the message. The identity of this entity can even
be opaque.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html