Gmail and the via

I was hoping to have a detailed post up today about the conditions where gmail presents the user with a “via” but time seems to have gotten away from me. But I can give you the conclusions.

  1. A via is presented to the user when you have a DKIM pass and the domain in the d= does not match the domain in the visible from address. In this case the interface shows via the d= domain.
  2. A via is presented to the user when you have a SPF pass, no valid DKIM (either a fail or no signature at all) and the domain in the return path is different than the domain in the visible from address. In this case the interface shows via the SPF domain.

This is an issue for ESP customers who are letting ESPs sign on their behalf. If your ESP is signing with their own domain, or their own domain is present in the return path, then all your mail will be displayed with “via” in the gmail interface.
In order to not have a via showing, you need to have either the return path or the d= value within the same domain as your visible from address. There are two ways to do this. Probably the easiest is to delegate a subdomain to your ESP so they can manage the signing and keys for you. Alternatively, you can manage DKIM keys yourself and just have your ESP sign with the private key you give them.
I have heard that recipients can remove the via by replying to a message or by adding the sender to their address books. My testing did not show that either method was effective in removing the “via” from the display.
Tomorrow, the work that went into these rather simple recommendations.

Authentication Cheat Sheet
Quote of the day

Related Posts

Defending against the hackers of 1995

Passwords are convenient for the end user, but it’s too easy to lose control of them. People share them with other people. People write them down, where they can be read. People send them in email, and that email is easily intercepted. People’s web browsers store the passwords, so they can log in automatically. Worst of all, perhaps, people tend to use the same username and password at many different websites. If just one of those websites is compromised (or even run as a password collecting scam) then those passwords can be used to attack accounts at all of the others.
Two factor authentication that uses an uncopyable physical device (such as a cellphone or a security token) as a second factor mitigates most of these threats very effectively. Weaker two factor authentication using digital certificates is a little easier to misuse (as the user can share the certificate with others, or have it copied without them noticing) but still a lot better than a password.
Security problems solved, then?

Read More

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.

Read More

Authentication Cheat Sheet

There are a several approaches to authenticating email, and the different authentication methods have a lot of different settings to choose from (sometimes because they’re useful, other times just because they were designed by committee). It’s nice that they have that flexibility for the complex situations that might benefit from them, but almost all the time you just want to choose a good, default authentication approach.
So here’s some short prescriptive advice in no particular order for “how to do email authentication at an ESP well” without the long discussions of alternative approaches and justification of each piece of advice.

Read More