BLOG

Industry News & Analysis

Aug 21, 2017

No Comments

August mini-recess

Blogging will be light through the end of the month. We’re headed to Wyoming to see the eclipse this weekend. As well, with all of the current political events happening it’s hard to focus on email right now.

So basically I’m giving myself permission to not blog daily through the end of August. I’ll blog as I have stuff to say. Some of those might be copies and pastes from comments I’ve made in other spaces. I seem to be on FB quite a bit these days – sometimes even email related.

I’ve also been asking questions and discussing stuff on some mailing lists. I had a flash of insight about how I think about deliverability differently from other people and am talking with some colleagues about it to make sure I can explain it well.

No Comments

Email address as identity

A few months ago I was talking about different mailbox tools and mentioned email addresses are the keys to our online identity. They are, email addresses are the magic key that authenticates us and opens access to different accounts.

The bad guys know this too. The Justice department recently announced a plea deal related to compromised email accounts. The individual in question gained access to faculty, staff and student email accounts. They then used access to these accounts to access Facebook, iCloud, Google, LinkedIn and Yahoo accounts.

Mediapost published an article this week referencing a survey performed at this year’s BlackHat conference.

Of 250 hackers polled, 32% said that accessing privileged accounts was the easiest and fastest way to get at sensitive data.

The second most effective route to data, cited by 27%, was access to user email accounts.

Email accounts are the keys to the kingdom. Protecting them is a vital part of protecting yourself online.

 

No Comments

Reengagement emails

By default I don’t load images in email. For one thing it lets me see who is using open / click data to measure engagement. This morning I got a reengagement email from my Senator. 

There are things I really like about this email and there are somethings I think they get a little wrong.

The good

This is a great subject line. I like the use of “ghosting” to describe what the email is about, and the inclusion of an emoji ghost. It all makes the subject line coherent and worthy of a click.

The other thing I really like about this is the large links, suitable for clicking on a mobile device. Really, people, some of us are old, have fat fingers or have phones with tiny text. Links, particularly for something like this, should be clickable on a phone.

The not so good

The not so good bit, though, is that I am reasonably engaged with my Senator’s emails. I mean, yeah, I don’t load images, but have clicked on some links in the past. Looking through my mailbox, the last time I clicked through on an email was June 9 or 10, just about 60 days before I got this message. That is more aggressive than I tend to recommend for most clients.

The weird

The weird bit is I’ve only received 2 messages since June 22, one of them being the re-engagement message. The other was an update related to my engagement activity on June 9. I know it’s August recess but the drastic downturn in volume coupled with a reengagement email makes me wonder if there isn’t something else going on.

Overall, this is a decent example of a reengagement email. It’s also a good example of a mobile email. I see designers fret about borders and alignment and never really see anyone discussing making links big enough to get your finger on. Really, I’ll take an ugly, unaligned email if it comes with a link big enough for me to click.

 

 

No Comments

State of Email Deliverability

I had other posts in the pipeline, but saw a link to the Litmus 2017 State of Email Deliverability Report and decided that deserved a mention here.

There’s all sorts of interesting data there, and well worth a download and read. I was, of course, interested in the “most problematic subscriber acquisition sources.” Senders having blocking issues or blacklist problems in the past 12 months use list rental, co-reg and purchased lists more often than senders that didn’t have problems.

Senders acquiring addresses through list rental are 104% more likely to be blacklisted than senders not using list rental. And they’re 47% more likely to be blocked.

These stats are the primary reason that most ESPs don’t allow list rentals, purchased or co-reg lists. They cause blocking and blacklisting. The ESP ends up having to deal with lots of problems and clean up the mess.

I’m unsurprised that lead generation by giving something away (a report, ebook, whatever) is related to problems. Most of these forms do little to no data checking and accept any and all fake data. There are fairly simple ways to enforce better data, but that does limit the spread of the information.

I am surprised to see signup through direct mail and catalog sales is so bad. Unless maybe people don’t know how to say no when asked for an email address over the phone. I know it seems awkward to say no when asked for an email address. Maybe some folks are giving fake addresses. I sometimes say I don’t have email, or just tell them no, they don’t need one.

The white paper itself is well worth a read. Go download it yourself (but don’t give them a fake email address!).

No Comments

Not a customer you want

Earlier this week one of my ESP clients contacted me. They have a new (potential?) customer dealing with some delivery challenges. Client was looking for advice on how to move the customer over and improve their delivery at the same time.

My advice was actually pretty simple: this isn’t a customer you want. Walk away.

I reached that conclusion about 10 seconds after I loaded the customer’s website. Because I know sometimes initial impressions are wrong, I did spend about 10 more minutes poking around. What I found did nothing to change my mind or convince me my initial impression was wrong. In fact, everything I found reinforced the belief that this was not a good customer for my client.

I sent my client an email explaining what I’d found and they agreed. Future deliverability problem averted!

Some of what I found inspired the conversations with spammers blog post from earlier this week. For instance, the website had two different signup forms, each pointing to a different ESP. Both links were dead.

Then I looked at the company’s whois record and found a bunch of cookie cutter websites, all with different domain names, all with the same broken subscription links.

I do this manually and I can’t fathom how you would automate this kind of checking. For me, it seems there absolutely needs to be a human in the loop. But I suspect that there are ways to automate these types of checks.

In any case, there’s a spammer looking for an email service provider. He’s having problems with IP reputation at his current ESP. He sends content and will even share with you the domain he’s using to collect email addresses. Pro tip: try and sign up for his mail before he signs your contract.

No Comments

Conversations with spammers

It’s amazing how many spammers try and fool deliverability into accepting a questionable list. All too often they fall back on a story. The basic points: a company you’ve never heard of collected millions of email addresses on a website hosted on a low end VPS.


I’ve never heard of your company. We’re just that much better at marketing. This list is guaranteed 100% opt in. Subscribers are desperate to hear from us. The mail is vital and important. We had some problems at our last ESP, but that’s just because they don’t understand our business model. And we had a brief problem with complaints. But they weren’t real complaints. Our competitors are signing up for the list and complaining to hurt out business. It’s not a list problem, it’s that we’re so dominant they have to subvert us. That’s just because we’re that much better at their jobs than anyone else.

You’re looking for deliverability help. Well, yeah, sometimes Gmail delivery is bad, but that’s simply because we won’t pay Google money for advertising. Google is so afraid of us they deliberately filter all this spectacularly wanted email into the bulk folder. They have problems with us as a business. Oh, and we might, sometimes, occasionally have a minor problem with Yahoo. But, again, it’s because we threaten them and they don’t want to have to compete on a level playing field.

If they’re a potential customer, I tell them about our services and offer a proposal. Once some company I’ve never heard of tells me their bad delivery is because global companies are afraid of them, there’s really nothing I can do. They’re unlikely to listen to me explain reality to them.

Sometimes, though, this conversation happens because I’m consulting for an ESP or an Agency. They’ve brought me in to discuss deliverability with a customer or vendor. In those cases, it’s my job to keep going.

Your site doesn’t actually have a signup form. That’s because we’re in the middle of an upgrade cycle and had some problems with the back end. [Alternative: We stopped collecting new email addresses because of their deliverability problems and removed the form.]

Your site has a signup form, and I signed up, but never got any mail from you. We disconnected the signup form while we handle our deliverability problems. [Alternative: That shouldn’t happen. We can forward you some messages instead.]

I have received spam advertising your company. We had a rogue affiliate that we discovered was spamming and we cut them off.

No, this is direct from your IP space. Oh, well, you must have opted in and forgotten about it. [Alternative: We had a rogue sales guy, but we fired him for spamming.]

Your company has only been in business for 3 years, this is an address I haven’t used since the ’90s. Oh, we probably bought a company that you opted into and so have permission that way.

That’s not really permission. Of course it is!

OK…. How can I help you. We want you to call Google / Yahoo / Hotmail and tell them we’re really a legitimate company that’s sending content and we shouldn’t be in the bulk folder.

What have you changed? Nothing! Why would we change anything? We’re great marketers. We have all these plans but need to get back to the inbox before we can implement them.

Um… there’s no filter setting for “laura says they’re a good sender.” They’re going to look for new sending patterns so let’s change a few things. Well, we recently removed 2/3 of our database, but it made no difference so we don’t know what else you think we can do.

Let’s talk about your technical setup.

2 Comments

July 2017: The month in email

August is here, and as usual, we’re discussing spam, permissions, bots, filters, delivery challenges, and best practices.

One of the things we see over and over again, both with marketers and with companies that send us email, is that permission is rarely binary — companies want a fair amount of wiggle room, or “implied permission” to send. There are plenty of examples of how companies try to dance around clear permissions, such as this opt form from a company we used to do business with. But there are lots of questions here: can you legitimately mail to addresses you haven’t interacted with in 5 years? 10 years? What’s the best way to re-engage, if at all?

We frequently get questions about how to address deliverability challenges, and I wrote up a post about some of the steps we take as we help our clients with this. These are short-term fixes; for long-term success, the most effective strategy is sending email that people want and expect. Engagement is always at the core of a sustainable email program.

We’ve also discussed the rise of B2B spam, and the ways in which marketing technologies contribute to the problem. B2B marketers struggle to use social and email channels appropriately to reach customers and prospects, but still need to be thoughtful about how they do it. I also wrote about some of the ways that marketing automation plugins facilitate spam and how companies should step up to address the problem. Here’s an example of what happens when the automation plugins go awry.

I wrote a few posts about domain management and the implications for security and fraud. The first was about how cousin domain names can set users up for phishing and fraud, and the second was a useful checklist for looking at your company’s domain management. We also looked at abuse across online communities, which is an increasing problem and one we’re very committed to fighting.

I also highlighted a few best practices this month: guidelines for choosing a new ESP and active buttons in the subject line for Gmail.

And finally, we celebrated the 80th birthday of the original SPAM. If you’re a regular reader of this blog, you probably already know why unwanted email is called SPAM, but just in case, here’s a refresher….

No Comments

TLS certificates and CAA records

Transport Layer Security (TLS) is what gives you the little padlock in your browser bar. Some people still call it SSL, but TLS has been around for 18 years –  it’s time to move on.

TLS provides two things. One is encryption of traffic as it goes across the wire, the other is a cryptographic proof that you’re talking to the domain you think you’re talking to.

The second bit is important, as if you can’t prove you’re talking to, for example, your bank you could really be talking to a malicious third party who has convinced your browser to talk to their server instead of your bank which makes the encryption of the traffic much less useful. They could even act as a man-in-the-middle and pass your traffic through to your bank, so that you wouldn’t notice anything wrong.

When your browser connects to a website over TLS it, as part of setting up the connection, fetches a “TLS certificate” from the server. That certificate includes the hostname of the server, so the browser can be sure that it’s talking to the server it thinks it is.

How does the browser know to trust the certificate, though? There’s not really a great way to do that, yet. There’s a protocol called DANE that stores information in DNS to validate the certificate, much the same as we do with DKIM. It’s a promising approach, but not widely supported.

What we have today are “Certificate Authorities” (CAs). These are companies that will confirm that you own a domain, issue you a certificate for that domain where they vouch for it’s authenticity (and usually charge you for the privilege). Anyone can set themselves up as a CA (really – it’s pretty trivial, and you can download scripts to do the hard stuff), but web browsers keep a list of “trusted” CAs, and only certificates from those authorities count. Checking my mac, I see 169 trusted root certificate authorities in the pre-installed list. Many of those root certificates “cross-sign” with other certificate authorities, so the actual number of companies who are trusted to issue TLS Certificates is much, much higher.

If any of those trusted CAs issue a certificate for your domain name to someone, they can pretend to be you, secure connection padlock and all.

Some of those trusted CAs are trustworthy, honest and competent. Others aren’t. If a CA is persistently, provably dishonest enough then they may, eventually, be removed from the list of trusted Certificate Authorities, as StartCom and WoSign were last year. More often, they don’t: Trustwave, MCS Holdings/CNNIC, ANSSI, National Informatics Center of India (who are currently operating a large spam operation, so …).

In 2011 attackers compromised a Dutch CA, DigiNotar, and issued themselves TLS Certificates for over 500 high-profile domains – Skype, Mozilla, Microsoft, Gmail, … – and used them as part of man-in-the-middle attacks to compromise hundreds of thousands of users in Iran. Coverage at the time blamed it on “DigiNotar’s shocking ineptness“.

In 2015 Symantec/Thawte issued 30,000 certificates without authorization of the domain owners, and even when they issued extended validation (“green bar”) certificates for “google.com” they weren’t removed from the trusted list.

So many CAs are incompetent, many are dishonest, and any of them can issue a certificate for your domain. Even if you choose to use a competent, reputable CA – something that’s not trivial in itself – that doesn’t stop an attacker getting certificates for your domain from somewhere else.

This is where CAA DNS records come in. They’re really simple and easy to explain, with no fancy crypto needed to set them up. If I publish this DNS record …

wordtothewise.com 0 issue "letsencrypt.org"

… that says that no CA other than letsencrypt.org may issue a TLS certificate for wordtothewise.com. There are a few extensions, for wildcard certificates and specifying that only a particular customer of the certificate authority may create certificates, but it’s all pretty simple.

There’s nothing to prevent a malicious certificate authority ignoring the record and issuing a certificate anyway – but that’d be conclusive proof of bad intent. It’s a very simple check for a CA to make, so it should prevent even marginally competent CAs from issuing certificates unless they’ve been listed in the domain’s CAA record. And it’s something it would be impossible to social engineer around at the CA. It’s not a perfect solution, but it’s spectacularly better than what we have now.

Support for CAA records has been added to the baseline requirements for all trusted CAs, so it’s something you’re likely to need to do soon. The first step is that at least some CAs will refuse to issue or renew TLS certificates unless the authoritative nameservers for a domain understand requests for CAA records. You don’t need to publish CAA records yet, though you should, but your DNS servers need to be able to handle requests for them.

This is probably going to be a fairly hurried upgrade for some companies. We use PowerDNS for our authoritative DNS servers, and it apparently doesn’t support CAA properly before version 4.0.4, which was released five weeks ago, and we got notification from our CA today that we needed to fix things. It’s probably a DNSSEC configuration issue …

So it looks like I’m going to spend some time over the next day or two diagnosing CAA and DNSSEC issues. I’ll share anything useful on Monday.

 

1 Comment

Another way Gmail is different

I was answering a question on Mailop earlier today and had one of those moments of clarity. I finally managed to articulate one of the things I’ve known about Gmail, but never been able to explain. See, Gmail has never really put a lot of their filtering on the SMTP transaction and IP reputation. Other ISPs do a lot of the heavy lifting with IP filters. But not Gmail.

While I was writing the answer I realized something. Gmail was a late entrant into the email space. AOL, Hotmail, Yahoo, even the cable companies, were providing email services in the 90s. When spam started to be a problem, they started with IP based blocking. As technology got better and content filtering became viable, improvements were layered on top of IP based blocking.

Gmail didn’t enter the mailbox market until the 2000’s. When they did, they had money, lots of hardware, and internal expertise to do content filtering. They didn’t start with IP based filtering, so their base is actually content filtering. Sure, there were some times when they’d push some mail away from the MTAs, but most of their filtering was done after the SMTP transaction. The short version of this is I never really pay any attention to IP reputation when dealing with Gmail. It’s just another factor. Unless you’re blocked and if you get blocked by Gmail, wow, you really screwed up.

Gmail does, of course, do some IP based blocking. But in my experience IP filters are really only turned against really egregious spam, phishing and malicious mail. Most email marketers reading my blog won’t ever see IP filters at Gmail because their mail is not that bad.

Other companies aren’t going to throw away filters that are working, so the base of their filters are IPs. But Google never had that base to work from. Their base is content filters, with some IP rep layered on top of that.

That’s a big reason Gmail filters are different from other filters.

 

4 Comments
  • OTA joins the ISOC

    The Online Trust Alliance (OTA) announced today they were joining forces with the Internet Society (ISOC). Starting in May, they will operate as an initiative under the ISOC umbrella. “The Internet Society and OTA share the belief that trust is the key issue in defining the future value of the Internet,” said Internet Society President and CEO, Kathryn Brown. “Now is the right time for these two organizations to come together to help build user trust in the Internet. At a time when cyber-attacks and identity theft are on the rise, this partnership will help improve security and data privacy for users,” added Brown.No Comments


  • Friday blogging... or lack of it

    It seems the last few Friday's I've been lax on posting. Some of that is just by Friday I'm frantically trying to complete all my client deliverables before the weekend. The rest of it is by Friday I'm just tired. Today had the added complication of watching the Trumpcare debate and following how (and how soon) it would affect my company if it passed. That's been a bit distracting, along with the other stuff I posted about yesterday. I wish everyone a great weekend.1 Comment


  • Indictments in Yahoo data breach

    Today the US government unsealed an indictment against 2 Russian agents and 2 hackers for breaking into Yahoo's servers and stealing personal information. The information gathered during the hack was used to target government officials, security employees and private individuals. Email is so central to our online identity. Compromise an email account and you can get access to social media, and other accounts. Email is the key to the kingdom.No Comments


Archives