Code Fix for Gmail Rendering Problems

Gmail recently implemented changes to its webmail environment that are adversely affecting how images are displayed in most browsers. We’ve created the below FAQ that describes the changes and some simple HTML code inclusions that will rectify these image display issues.

Tell me more

Categories: Explanation How-To View Comments

Snow-shoeing and how to avoid it

As you may know, just in time for Christmas, The Spamhaus Project recently announced their new anti-snow-shoeing service the CSS component of the SBL: http://www.spamhaus.org/css/index.lasso

Spamhaus also has an http://www.spamhaus.org/news.lasso?article=650>article that offers some good information.

The CSS is the second such list to appear online; Invaluement was the first out of the gate with their ivmSIP/24 zone.

Both the SBL and ivmSIP/24 are part of the batch of checks we run constantly, against Return Path Certified and Safe whitelisted IPs. We also run a number of other tests to flag activity that is frowned upon by the receiving community.

SURBL, the domain blacklist, just announced their new, experimental zone of snowshoe domains, XS.

So, what is snowshoeing and how do you avoid such a pitfall?

Snowshoeing is, in a nutshell, spreading mail over IP ranges, domains or name-servers, in an attempt to lessen the impact of poor reputation upon an individual element.

Tell me more

Categories: Explanation View Comments

Prioritization of Spam at Gmail

UPDATE: The original version of this post had a link to the main Google YouTube channel, which had featured the spam video. After we published this, they swapped in a new video, causing confusion for some readers. We’ve now updated the link to go directly to the video about Gmail spam priorization. Sorry for any confusion we caused.

Google’s Gmail can be somewhat of a mystery. They do things a bit differently than other large ISPs and they do it well. From our perspective in deliverability, Gmail is always a tougher ISP to understand and troubleshoot.

Most of the experts know that Gmail relies heavily on their user feedback and “this is spam” vs. “this is not spam” voting, but many questions remained around how they really prioritize complaints. Recently, they posted a video to YouTube that helps us understand just a little more and pull back a bit more of the mystery.

Google’s Matt Cutts says Google does order complaints, and that typically, they try to think about what the impact is on the user. So, if they get …

Tell me more

Categories: Explanation 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

Delivered May Not Mean To the Inbox

It’s no surprise that email marketers are often confused about the difference between a bounce rate and an inbox deliverability rate. Most email broadcast systems in the U.S. and Europe report something called “delivered.” It’s usually a pretty high number – like 98% or 93%. And your ESP would like you to judge them on that number, because it’s really high, and it’s easy for them to be confident that it will stay high.

The problem is that most vendors define “delivered” as the inverse of your bounce rate – the number of records on your file that either no longer exist (a hard bounce) or are having temporary delivery failure (a soft bounce), perhaps due to an out of office reply or a full mailbox or some glitch in the ISP server.

Most marketers who keep their lists clean and have good permission practices have a bounce rate of 1%-5%. Even if you outsource your bounce handling to your ESP, you are still responsible for how they manage the removal of names – so be sure you understand what they are doing on your behalf. Your bounce rate is a good number to have included in your reports. It tells you something about your list hygiene. But it tells you nothing about what happens to your emails. …

Tell me more

Categories: Explanation Standards 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

Searching for Truth in DKIM: Part 2 of 5

In part 1, we explained that the DKIM “d=” value identifies the domain name which signed the message, which may be a different domain name from the author of the message.

Tying the signing and author domains together requires an additional standard: Author Domain Signing Practices (ADSP). In IETF parlance, the “author domain” is the domain name in the From: header, so ADSP is a way for the author domain to publish a statement specifying whether any other domain name should ever sign a message purporting to be From: that author domain….

Tell me more

Categories: Explanation View Comments

Searching for Truth in DKIM: Part 1 of 5

DomainKeys Identified Mail (DKIM) is the leading email authentication technology, supported by major ISPs including Google, AOL, and Yahoo! (who invented its predecessor), popular mail server software like Sendmail, and many of the best minds in email technology. But if you peruse the archives of the IETF DKIM mailing list, or start up a conversation at MAAWG, it might appear that there’s still a lot of disagreement about what a DKIM signature actually means.

Often, anyone attempting to describe authentication turns to analogies: a driver’s license, or a license plate on a car, or a passport — all saying that you are who you say you are, but not (by themselves) proving that you’re trustworthy. The trust measurement is external to DKIM: a reputation score, or third-party certification status.

But what, exactly, is being trusted? What’s being measured? …

Tell me more

Categories: Explanation View Comments