CircleID

Once you've determined that you can trust the signer of a message, as we discussed in part 3, it's easy to extrapolate that various portions of the message are equally trustworthy. For example, when there's a valid DKIM signature, we might assume that the From: header isn't spoofed. But in reality, DKIM only tells us two basic things:

1. Does the message have a valid signature? (yes or no)
2. Which identifier signed the message? (the d= domain)

DKIM uses a cryptographic signature based on a hash of the message, so if the signature is valid, we also know that the message wasn't changed in any way between the time it was signed and the time the signature was verified. What we don't know, and can't know, is what happened — intentionally or unintentionally — before it was signed.

For example, I could write a message where I claim to be Joshua Norton, Emperor of these United States and Protector of Mexico. It'll be signed when I send it to you. But DKIM doesn't tell you if it's true that I'm Emperor Norton I — and doesn't even tell you if it was actually me making that claim. All you really know is that the message has a valid signature and was signed by returnpath.net.

That's a fairly broad example, though, so let's dig through some thorny specifics.

In most mail client software, the only identifier the recipient ever sees is the From: header (or, worse, all they see is the "friendly from" — but that's another issue.)

Lacking a strong ADSP assertion, DKIM does not tell you if the domain in the From: header is truthful or not.

A common vector for phishing or malware distribution is to send a message that looks to recipients as if it's from a known and trusted brand, and include links to that brand's web site — except for one link, which goes to the bad guy's site. While DKIM can tell you if the message was modified, the bad guy can apply a new, perfectly valid signature via his own domain — after which DKIM does not tell you whether the links are truthful or not.

Similarly, phishing experts talk about "close cousin" domains — yahooo.com vs. yahoo.com, ebay-paymints.com vs. payments.ebay.com, et cetera. DKIM does not tell you whether the domain is truthful, or is trying to fool recipients.

And DKIM itself includes an additional identifier, the "i=" value, which looks like (but isn't) an email address. The signer can set i= to whatever they want, as long as the part after the @ is the same as the d= domain. Cisco uses this to identify individual users: i=santaclaus@cisco.com. More common, I'd expect, will be use of i= to denote distinct mailstreams or internal divisions: i=transactional@example.com, i=marketing@example.com, i=nyc-office@example.com.

Thing is, i= is an opaque identifier. There's simply no way for anyone outside of the signing domain to know whether marketing@example.com is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. DKIM does not tell you what it means, or if it'll mean the same thing in the signature of another message. DKIM does not tell you if i= is truth, or is consistent; thus, reputation is more likely to accrue to the d= value.

What DKIM does do is simple, and powerful. Knowing that you have a message with a valid signature isn't enough by itself. Knowing the d= identifier, the signing domain, isn't enough by itself. But once we do know those things, a presumption of truth can be based on trust.

Domains like ebay.com are likely to have a good reputation, both on their own and verified by certification programs like Return Path's Sender Score Certified — which indicates that they're trustworthy. When a message is signed by ebay.com, we can (almost always) safely assume that other characteristics of the message are equally trustworthy. We can trust the From: header, and the links, and the images, as much as we trust the domain. But when a message is signed by ebay-paymints.com, which would have bad or no reputation, we can safely assume that all characteristics of the message are equally untrustworthy.

In the final part of this series, we'll make some predictions about what all this trust (or distrust) and truth (or untruth) will mean to you.

(This article was originally published by Return Path.)