What Ever Happened to ADSP?

Many mailbox providers are concerned about liability and expectations: they know they’ll be blamed by their users and even by senders when a senders’ ADSP policy leads to a legitimate (but unsigned) message being discarded. They’re also concerned that they’ll be expected to provide technical support for every mail operator who wants to use ADSP. Similarly, those same mail operators — whether senders of bulk marketing email, enterprise Exchange administrators, or mailbox providers themselves — are worried that there may be mail streams that aren’t applying DKIM correctly, or aren’t authenticating at all.

Tell me more

Categories: Explanation Standards View Comments

Microsoft tests DKIM and ADSP

An engineer from Microsoft recently shared some of the thinking behind Hotmail’s adoption of DKIM and ADSP.

Tell me more

Categories: Explanation View Comments

Is Amazon Playing Chicken With Mailbox Providers?

The market for an easy outbound mail API “in the cloud” may well be gigantic; it’s pretty obvious that email is the last thing that the latest social/cloud/whatever startup entrepreneur wants to think about. When the next hot site discovers that deliverability isn’t ever guaranteed, will they blame Amazon, or will they blame the mailbox provider who rejected the message?

Tell me more

Categories: Commentary View Comments

Authenticating the Most Important Messages

Legitimate third parties — SalesForce, social networks, the 3rd party benefit sites favored by HR departments — forge your domain in mail to your users all the time. Keeping track of each of these can be impossible. Worse, in an ISP environment, you don’t really have that much control over what your users send.

But that doesn’t mean you can’t still gain some benefit from DKIM.

Tell me more

Categories: Explanation View Comments

Don’t Make It Easy For The Phishers

There’s no such thing as a Final Ultimate Solution to the Spam Problem, or a Final Ultimate Solution to the Phish Problem. What works is security in layers — and more layers, and more layers, and more layers. Yet in the search for that FUSSP or FUSPP, some of the simpler, lower layers have been skipped over.

One of these, believe it or not, is email authentication.

Tell me more

Categories: Explanation How-To View Comments

Reporting DKIM Failures with ARF

draft-ietf-marf-dkim-reporting creates a new ARF feedback type, simply “dkim”. It also introduces some new metadata fields, containing DKIM-related information….

Tell me more

Categories: Explanation Standards View Comments

DKIM: Not Shiny, But Very Important

When a new iPhone or Palm device is released or Google announces a new OS, everybody hears about it. These are, for a short time, the shiniest thing in the tech world. One reason for this phenomenon — perhaps the primary reason — is that they directly affect end users. They’re things that early adopters drool over and stand in line for, while slower adopters ask “Why would I want that? My 8-track player still works perfectly.” In the meantime, the U.S. Department of Justice is investigating whether domestic telecommunications companies have been engaging in “monopolistic and anticompetitive practices” again — which could have much larger, longer-lasting effects on how we access and utilize the internet in this country. But, it’s not shiny and immediate, so that gets far less attention.

Even in the email industry, shininess is rarely an accurate indication of importance or impact. Google removed the “beta” label from Gmail a few weeks ago, but Gmail is still basically the same as it was before. Spammers are mentioning Michael Jackson more often than they did before he died, but so is everyone else. And Return Path has published two more studies, proving twice again that email marketers need to pay more attention to deliverability. …

Tell me more

Categories: Explanation View Comments

Searching for Truth in DKIM: Part 5 of 5

Throughout this series of articles we’ve been talking about DKIM, and what a valid DKIM signature actually means.

Part 1 explained that the DKIM “d=” value identifies the domain name which signed the message, which may be different from the author of the message. Part 2 described how the author domain can gain some control over whether any other domain name should ever sign a message purporting to be From: that author domain. Part 3 discussed how the reputation of a d= domain leads to a reliable determination of trustworthiness, while part 4 reminded us that truth cannot be assumed until trust is certain.

What this means for senders (of any type) is that …

Tell me more

Categories: Explanation View Comments

Searching for Truth in DKIM: Part 4 of 5

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 …

Tell me more

Categories: Explanation View Comments

Searching for Truth in DKIM: Part 3 of 5

Last year, MAAWG published a white paper titled Trust in Email Begins with Authentication, which explains that authentication (DKIM) is “[a] safe means of identifying a participant-such as an author or an operator of an email service” while reputation is a “means of assessing their trustworthiness.”

Regular readers of this blog already know that reputation systems based on IP addresses, including our Sender Score, are used by many ISPs and anti-spam vendors to determine which mail to accept, which to reject, and which to subject to additional filtering before making a delivery decision. There, the identifier is the IP address.

The reason this sort of reputation works for delivery decisions is that it’s an attempt to measure whether the sender of a message can be trusted to send mail that the recipients want — or, more accurately, whether the IP address of a message can be trusted to send mail that the recipients won’t complain about. We also mix in the concept of safety, largely in the form of how likely it is that the IP address is sending phishing scams or similar bad stuff. …

Tell me more

Categories: Explanation View Comments