[ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor breaks email semantics

[Douglas Otis]

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