Recent Posts

October 2014 – The Month in Email

October was action-packed at WttW. We wrapped up some big and interesting client projects (look for some case studies soon!), attended another great M³AAWG conference, and made an exciting announcement that we’re hiring a deliverability specialist. The combination of these frees up some more of my time for blogging, which I’ve really missed. Look for more from me in November and December.

The best time to send email

This subject comes up over and over again. Many senders are convinced that there is a best time to send email. Countless research hours have been dedicated to finding that best time to send email. Numerous blog posts discuss what the best time to send email is.
From my perspective, there are better places for senders to spend time than figuring out what the exact right time is.But, senders still ask when the best time to send mail is.
There are a lot of reasons I can come up with as to why there’s no best time to send email. But the really big one is that when you send a mail has no impact on when it gets delivered. There are multiple steps between hitting the send button and the mail being delivered to the inbox totally outside the control of the individual sender.
Email is designed as “store-and-forward.” This means there are potential delays at multiple steps inside the process.
Sending queues are called queues for a reason. Emails are sent out individually, particularly when an ESP uses VERP as part of its sending. There is actually a time overhead for making a connection to a recipient server and sending the email.
Receivers have queues, too. They can only accept so many incoming connections at a time. They have limited resources to accept all the mail their users want.
Receivers may delay mail between accepting it at the MX and delivering it to the inbox. This isn’t ideal and it’s not usual, but it can happen.
Recipients using IMAP accounts may not check mail regularly. They may only collect mail a few times a day.
These are only a few of the reasons that send time doesn’t necessarily equate with delivery time. Of course, 99% of the time email is mostly instantaneous. The internet is robust enough that a message sent is delivered seconds later. I see it happen all the time, when colleagues and I send email during calls. But, when mail fails, it sometimes fails spectacularly. Back in the dark ages (of the early 90s) I had an email that took almost a year to get to the recipients. Best I can tell, it got stuck somewhere in the depths of a machine in the middle of the university mail system. Eventually that system fell over and someone noticed and rebooted it (maybe it was walled up somewhere?). The reboot shook my message out of where ever it was stuck.

The long tail of domains

I frequently get clients telling me that they have about 15 (20, 30) major domains on their list, and then a long tail of domains with only a couple of recipients. If you sort simply by the left hand side of the @, that’s true.
When you’re sending email, it’s not just the domain in the email address that is important. Of equal importance is the MX. The MX is what actually handles the mail and where many filters are applied. Sorting by MX, instead of simply recipient domain, can identify that most of your small business clients are hosted at a particular provider. The number of subscribers behind that filter may be enough to push that filter into your top 10 or even top 5 recipient domains.
There’s a much smaller tail when grouping recipients by MX domain. It makes it much easier to understand where blocks are happening. I have even seen cases where clients didn’t realize they were blocked at a commercial provider because they only saw the “onesie twosie” domains as undeliverable. They missed a real problem with blocking because they were looking at the wrong data.
I sometimes get the side eye from some ISP folks if I use the term receiver (because, well, they’re senders as much as they are receivers). But I use receiver to help distinguish between the recipient domain and the actual domain handling the email.
When was the last time you looked at your delivery by filter or MX rather than by recipient domain? What did you find?

Superstition, correlation and reality

I’m not a huge baseball fan, probably a side effect of growing up in a city with no MLB team. But I do enjoy the social aspects of rooting for local teams when they’re winning big games. Last night I was following the World Series score online and switched over to watch the last inning. I posted something about the game on FB just about 30 seconds before the Giant’s outfield bobbled what should have been a single (at best). I immediately posted an apology, “Sorry about that, shouldn’t have said anything!”
Do I really think that my post somehow cursed two outfielders and caused them to bobble a simple play? No, of course not. But it is a very human response. In fact, there’s an entire advertising campaign centered around the the weird things people do while watching sports.
There is a lot of superstition in email delivery, too. I think that’s a combination of filtering necessarily being a black box, human’s built in tendency to see patterns in random data, and a need to be able to control and affect outcomes.
Figuring out cause and effect in the real world is not trivial. In my research days we set out to control as many confounding factors as possible so we could demonstrate the cause and the effect. That’s really hard to do when you’re not at a lab bench. In the real world, we can’t always control things directly. Instead, we have to rely on statistics and representative (or non-representative) samples.
Delivery isn’t even close to a science and one of the major issues is that filters are always changing. I’ve certainly seen occasions where multiple clients, or colleagues, were having problems delivering to one ISP or another. One of my clients made a change and saw their delivery improve. They patted themselves on the back for figuring out the problem. At the same time, though, other folks saw their delivery improve without making any changes. I can’t always convince people that whatever they did had nothing to do with their delivery improving.
The flip side is I can’t always convince people to stop doing somethings that they don’t need to do. I see a lot of mail with both DomainKeys and DKIM signatures. In most cases both signatures have the same selectors. DomainKeys is deprecated. No one, and I mean no one with a modern email system, is checking DomainKeys without checking DKIM. Senders can safely stop signing with DomainKeys and have nothing happen. It doesn’t matter, lots of ESPs and sender sign with both. They’re not going to change it. I’ve had multiple groups tell me they’re afraid to stop signing because it might hurt their delivery.
The reality is I didn’t make the Giant’s outfield bobble the ball because I posted to FB that I was watching the bottom of the 9th inning. The reality is that DomainKeys is deprecated and there’s no benefit to signing with both DomainKeys and DKIM. The reality is we are humans and we are inherently superstitious. Most of the times our superstitions are harmless. But sometimes they cause us more work than we need to do and provide no tangible benefits.

Disposable addresses

Both Steve and I have blogged about how we use tagged addresses to monitor and manage our incoming mail. This is not something unique to our system, but rather a feature that’s existed in many mail systems for a long time. Many unix systems support tagged addresses out of the box, but there are also commercial MTAs and even some webmail services that support tags.
Gmail offers “+ addressing” where users can use unique tags after their username. This gives every gmail use an unlimited number of addresses to use. Any address gets leaked or compromised, and you can set filters to ignore future mail to that particular tagged address.
Yahoo offers up to 500 unique addresses per account. Initially this was a service provided by OtherInbox, now owned by Return Path, but it’s not clear if that’s still the case.
Spamgourmet has been offering disposable addresses since 2000. Their system has a built in limit on the number of emails a particular email will receive, which can help control the incoming volume.
Spamex is another provider of disposable addresses that’s been around for years and is providing services that allow recipients to control their incoming mail.
New on the scene is MeAndMyID.com who popped up in the comments here today. They are offering disposable addresses, free for a lifetime, if you sign up soon.
There are also the “short term” or “open inbox” disposable addresses like Malinator or 10 Minute Mail
I find disposable addresses invaluable for sorting through the mail coming into my account. A bank email to an address I didn’t give the bank? It’s a phish. A pizza hut email to an untagged address? Not real. Target emails to an address only given to Amazon? Amazon is selling or giving addresses away in violation of their privacy policy. Unexpected email from a vendor, but to a tagged address? Time to unsubscribe as I’ve lived this long without their mail.

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.

My first thought was “oh, no, Pizza Hut is spamming, wonder who sold them my address.”
Then I remembered that iOS is horrible and won’t show you anything other than the Friendly From and maybe it was some weird phishing scheme.
When I got to my real mail client I checked headers, and sure enough, it wasn’t really from Pizza Hut. I’m guessing actually malware, but I don’t have a forensics machine to click the link and I’m not doing it on anything I can’t wipe (and have isolated from the rest of my network).
The frustrating thing for me is that this is an authenticated email. It not from Pizza Hut, the address belongs to some company in France. Apparently, that company has had their systems cracked and malware sent through them. Fully authenticated malware, pretending to be Pizza Hut, and passing authentication on various devices.
Pizza Hut isn’t currently publishing a DMARC record, but in this case, a DMARC record for Pizza Hut wouldn’t matter. None of the email addresses in the headers point to Pizza Hut.
I spent last week listening to a lot of people discussing DMARC and authentication and protecting people from scams and headers. But those all the protocols in the world won’t protect against this kind of thing. Phishing and malware can’t be fixed by technology alone. Even if every domain on the planet published a p=reject policy, mail like this would still get through.

Three things marketers should do when domains are retired

A few weeks ago I was alerted to a domain change for INGDirect. The ingdirect.com domain is being retired and all users are migrating to the capitalone.com domain. As part of this change usernames are NOT being transferred, so if you have @ingdirect.com addresses on any B2B mailing list, you will need to drop those addresses and find the new contact information for the subscriber.

Gmail announces new "Inbox" product

Gmail announced today on their blog a new product “Inbox” to help make the inbox more useful and more of a center of activity.
“We get more email now than ever, important information is buried inside messages, and our most important tasks can slip through the cracks—especially when we’re working on our phones. For many of us, dealing with email has become a daily chore that distracts from what we really need to do—rather than helping us get those things done.”
Inbox lets people organize their emails to help them get things done. Creating tasks, organizing threads and discussions, all of that can now be done in this new application.

Bounces at Verizon

There have been lots of reports of Verizon rejecting valid email addresses for a few hours this morning. They seem to have fixed things now but you probably want to make sure you didn’t suppress those addresses.

SWAKS: the SMTP Swiss Army Knife

flash_m_laser_1200_900
SWAKS is a general purpose testing tool for SMTP. For basic SMTP testing it’s a more convenient, scriptable alternative to running a transaction by hand, but it also lets you test things that are difficult to do manually, such as authentication or TLS encryption.
It’s a perl script that installs fairly easily on OS X or any Linux/unix system (and can be installed on Windows, if you have perl installed there).
It’s pretty well documented, but it can be a bit overwhelming to start with. Here are some simple recipes:
Send a test email: