DKIM "i=" vs "d=" and Reputation

This really should be part seven of a twelve part series or some such as it deals with an aspect of DKIM that’s really important, but is way down in the details of implementation. (dkim.org is a reasonable place to start for a general overview of DKIM).
There’s an apparently endless thread on the DKIM-SSP spec development mailing list at the moment about the differences between two fields in a DKIM signature that could be used to tie a senders reputation to. Several ESP delivery folks asked me to explain what everyone was talking about, and this post is a first cut at that.
“i=” vs “d=”
There are two possible fields in a DKIM signature that could be used to identify the sender of a message, and so to tie a sender history and reputation record to. They are the so-called “i=” and “d=” field, from the syntax used to include them in the signature.

d= is the domain of the entity signing the message. It’s the unique identifier for that signer.
As DKIM is domain based, it tells you only that the message was authorized by a given domain, it doesn’t tell you who within that domain sent it. One obvious way of passing that information is to use subdomains (billing.example.com vs aardvark.example.com). Another would be to use something like a MySender header – say MySender: alice@example.com and have the DKIM signature authenticate that header. That way when you look at the email you see that it is signed by or on behalf of example.com, and that the sender (who is either example.com or somebody they have authorized to send mail on their behalf) is asserting that the author of the message is actually “alice@example.com” rather than just somebody related to example.com.
The email address in that signed MySender header needn’t be the same as any other header, so it may be different to the From, the Reply-To and everything else. It may not be visible to the final recipient at all.
The i= field is almost the same as that MySender header. It’s an additional bit of data that the signer of the message (the domain in the d= tag) is asserting to be the identity of the sender of that message. There are a few trivial differences, but that’s the gist of it.
Those trivial differences are…

1. The domain part of the email address in the i= tag must be the same as or a subdomain of the domain in the d= tag.
2. The DKIM public key record associated with a particular domain and selector may (and in practice, probably will if the sender uses i= at all) assert that the domain part of the email address in the i= field must exactly match the domain in the d= field. The value of this is unclear, but it might allow a DKIM verifier to avoid a fair bit of DNS work in some cases.
3. The DKIM public key record associated with a particular domain and selector may (but in practice likely never will) assert that you should not consider the signature valid unless the local part of the i= field matches the (wildcarded) string in the g= field of the public key record. In practice I expect this to never be used.

So, summarized, if the d= field is d=example.com and the mail was sent by alice@example.com you’d expect the i= field to be one of two things “i=@example.com” or “i=alice@example.com”.
“@example.com” just means that the person who sent the message is at example.com – in other words it says nothing that’s not already said by the “d=example.com” field. In fact, if i= is omitted altogether, this is what you assume it’s value is.
“alice@example.com” means that example.com (or someone they’ve shared one of their private keys with) is asserting that the sender of the message is “alice@example.com”.
What are they for?
The intended use of i= is the corporate or ISP environment where you may want to DKIM sign mail from users, or allow users (or entire divisions or offices) to DKIM sign mail, but also provide some basic level of enforcement that marketing can’t sign mails claiming to be from sales and vice-versa in a corporate environment.
In a consumer ISP environment, it would be possible for earthlink.net to create a DKIM private/public key pair and give the private key to steve@earthlink.net, to allow him to sign his own email with the d=earthlink.net domain, but require him to put “i=steve@earthlink.net” in each message, and have DKIM verifiers refuse to verify the message if he omits the i= field, or puts i=bob@earthlink.net there instead.
I don’t expect anyone to use i= much at all, and there’s no obvious, sensible use case for it in the context of ESPs or other bulk senders at all. That doesn’t mean that ESPs may not use it (to stash a unique customer identifier in, say) but there’s no clear use case for recipients to pay much attention to it in reputation terms, so not much drives the ESP to make serious use of it.
Reputation
If the message is signed by the ESP (d=esp.com) then the ESPs reputation is the one that’ll be used to judge the message. If the message is signed by (or, more likely, on behalf of) the customer (d=bricknmortar.com) then the reputation of the customer is the one that’ll be used. Even if, in the former case, the message is signed with “i=bricknmortar@esp.com d=esp.com” I’d be amazed if any mechanical reputation system treated that particularly differently to just “d=esp.com“. That all may change as DKIM gets more widely deployed and people get more comfortable with the semantics, but I think it can safely be ignored for the next year or two.
I expect most smarter ESP customers to push for using their own domain for signing, probably by delegating a subdomain to the ESP, rather than signing with the ESPs domain. This gives them the advantage of their own reputation, mostly unaffected by the reputations of other customers of the ESP and which can be transferred from one ESP to another.
I’m not sure which approach the ESPs will push their customers to use, as there are conflicting business pressures. A reputation tied to the customer rather than the ESP reduces the impact of customers reputations on each other – similar to the advantages of one IP to a customer, but more so. But it also makes it easier for a customer to take their business elsewhere without sacrificing the reputation they’ve built.