[ietf-dkim] The (really) latest SSP draft

[Douglas Otis]

On Oct 22, 2007, at 2:16 PM, Mark Delany wrote:

> On Oct 22, 2007, at 1:37 PM, Jon Callas wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> So if he said i=subdomain.example.com, then surely the From/Sender
>>> can be expected to be from that subdomain; and if he said
>>> i=someone at example.com, then surely recipients can assume that
>>> 'someone' had indeed played some part in sending it.
>>>
>>
>> Absolutely not. DKIM is a protocol in which one administrative domain
>> speaks primarily to other administrative domain. It's not a domain- 
>> to-
>> user protocol nor a user-to-anything protocol. The i= parameter can
>> be anything the signing domain wants it to be. It is unlikely to be
>> an outright lie (for example, I mark all mail coming from alice with
>> bob), but it may be.
>>
>
> I liken i= to IDENT (RFC1413). The values *may* be meaningful to  
> the administrative domain, but that's all that can be said about it.

I agree with both of these statements.

There is only one requirement expressed by the base draft.  The  
domain of the i= parameter, when present, must be the same or within  
a sub-domain of the d= parameter, otherwise the signature is invalid.

Having the i= parameter match an address within some originating  
header may prioritize signature evaluation, as not all signatures may  
be checked.  Ensuring acceptance would be the intent of the i=  
parameter, rather than indicating who authored the message.  (See  
section 4.2.)  To even determine whether the i= parameter matches  
some header may also involve internationalization translations.  It  
seems doubtful this part of DKIM will safely play a significant role  
within any user interface.

For example:

From: billy at example.com
DKIM-Signature: i=Grand-Imperial-Phoobah at example.com; d=exmaple.com

Per DKIM base spec section 6.3

"If the message is signed on behalf of any address other than that in  
the From: header field, the mail system SHOULD take pains to ensure  
that the actual signing identity is clear to the reader."

Not including billy in the i= parameter might create acceptance  
problems based upon section 4.2, and 6.3 stipulations.

The base specification does not state that the i= parameter must be  
an accurate indicator of who authored the message.  Instead, it  
suggests that by not including a matching identity, the signature may  
not be evaluated, or that the From header may not be presented as  
desired.  Instead, the base specification offers good reasons for  
signing domains to not care whether an i= parameter has been  
validated.  From their view, the i= parameter should be included to  
improve the acceptance and presentation of your domain's messages.   
Recipients, on the other hand, should be advised to ignore this now  
meaningless parameter.

-Doug