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…
- 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.
- 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.
- 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.
RSS - Posts
The fact that DK does not require the signing-identity to match any of the mail headers is interesting. This allows ESPs to act as signing-identity, thus avoiding the hassle of having all customers registering DK records. However the standard also says that it is up to the verifier to determine how an arbitrary signing-identity is handled. Do you have experience that this d=esp.com scheme actually works? Would this also enable the ESP to receive Yahoo FBL complaints for the From: domains of it’s customers?
Yes, signing with d=$ESP will work, and will allow the ESP to receive DKIM based feedback loops.
However doing so means that you don’t get most of the advantages of DKIM – portable reputation tied to the identity of the author of the message. Were I looking for an ESP I would never use one that used DKIM, but only signed with it’s own domain.
You can get the best of both worlds by signing each email twice – once with the ESP domain and once with a domain delegated from the customer (so that the customer adds one NS record delegating a subdomain of their DKIM DNS tree to the ESP and the ESP handles everything else DKIM related). The customer delegated domain attaches their reputation to the message, while the ESP domain allows simple signup for DKIM based FBLs (simpler and easier to maintain than IP based).
The only problem with that is that many of the commercial smarthosts used by ESPs have very limited DKIM signing abilities, and may not be able to sign twice. Some of them can’t even sign with an appropriate domain. If ESPs tell their vendors what they want I’m sure that’ll change.
I’ve gone into more detail about this style of ESP deployment in the dkim-core draft, at http://dkimcore.org/dkimcore.pdf
I followed your suggestion to ask my vendor for enhanced DKIM signing abilities. Port25 just released an update of their MTA that supports signing arbitrary sender domains with a specific DKIM identity. Using that, I tested the d=esp.com scheme in Yahoo, Gmail and AOL, which all showed a “pass”. However, like you said, smart ESP customers should use (and protect) their own domain.
Regarding ESPs and Senders, it seems that i= could be the only way to differentiate the ESP reputation from the sender reputation (an ESP customer).
For example if the ESP uses a fixed envelope-sender for each customer, then an ISP may be able to assign a different reputation to each ESP customer.
But this implies that ESP has would dismiss VERP and find another bounce management system.
Is it correct?
No, there is never any need to use i= in a typical ESP setup, and I don’t expect many receivers to make any use of it in general for reputation.
Also, the domain that is used to sign the message need not be the domain used in the return path, nor the from address. Nothing about DKIM will impact use of VERP at all.
There are many ways an ESP could use DKIM, to get the reputation and feedback setup they want, but a typical DKIM setup for an ESP might involve signing each message twice, once with a single domain used by the ESP to sign all email (primarily for feedback loops) and once with the customers domain (primarily for reputation).
http://dkimcore.org/deployment/esp.html goes into that sort of DKIM configuration for a typical ESP in quite a lot of detail.