Recent Posts

Lets Encrypt Everything

Using ~~SSL~~ TLS to protect data in transit and authenticate servers you contacted originally required specialized software, complex configuration and expensive and complicated to require certificates.
The need for specialized software is long since gone. Pretty much every web server and mail server will support SSL out of the box.
Basic server configuration is now pretty simple – give the server a couple of files, one containing the TLS certificate and the other the associated private key. (Configuring a server securely, avoiding a variety of attacks on weak parts of the SSL/TLS protocol, can be a bit more work, but there are a lot of tools and documentation to help with that).
But acquiring a certificate from a reputable provider is still expensive enough (one Certificate Authority’s list price for entry level certificates is $77/year, though the same certificates are available for <$10/year from resellers, which tells you a lot about the SSL certificate market) that you might not want to buy one for every endpoint.
And the process of buying an SSL certificate is horrible.
First you have to find a Certificate Authority or, more likely, a cheap reseller. Then it requires generating a “Certificate Signing Request” – something that can be done in dozens of different ways, depending on the device it’s being generated for. The user-friendliest way I’ve found to do it is to use the openssl commandline tools – and that’s really, really not very friendly.
Then you need to log in to the CA, upload the CSR, follow a bunch of directions to confirm that you are who you say you are and you’re entitled to a certificate for the domain you’re asking for. That can be as simple uploading a file to a webserver that serves the domain you’re getting a certificate for. Or it can turn into an inquisition, where the CA requires your home address and personal phone number before they’ll even talk to you.
Then you need to use the same browser you submitted the CSR request from to get your certificate – as the CA doesn’t do all the cryptography itself, it relies on your web browser for some of it. There are some security-related reasons why they chose to do that, but it makes for a fragile – and near impossible to automate – process. And the attempts to upsell you to worthless “security” products are never-ending.
help
There’s probably more horribleness, but it’s 9 months since I last bought a certificate and I may have forced myself to forget some of the horror.
There’s no need for it to be that painful. It’s easy to mechanically prove to a Certificate Authority that you control a domain in the same way you prove ownership to other companies – put a file the CA gives you onto the webserver, or add a special CNAME to your DNS.
And once you’ve proved you own a domain a certificate for that domain could be generated completely automatically. For the most common web setups you could even prove domain ownership, generate a new certificate and install that certificate into the webserver entirely automatically.
I’m sure there’s some reason other than “because we’re milking the SSL cash cow for all it’s worth” that dealing with most Certificate Authorities is so painful and expensive. But there’s no need for them to be that way.
This year there’ve been several groups who have stepped forward to escape the pain of dealing with legacy Certificate Authorities, at least for basic domain verified TLS certificates (as opposed to the “green bar” extended verification certificates you might want for, e.g. an eCommerce site).
Lets Encrypt has been one of the higher profile new CAs who are driving this effort. With the help of ACME, an open protocol being developed for issuing certificates automatically, they’re providing zero-cost TLS certificates. They’re hoping that, to use their phrase, you’ll encrypt everything, using TLS to encrypt traffic everywhere it makes sense to do so.
So, how does it work?
coyote
It works wonderfully well.
Lets Encrypt is still in public beta testing for a few more weeks, but I just got beta access. Installing their client tool on a reasonably recent Linux box just took copy-pasting two commands and waiting a minute.
The tool supports a variety of different ways to request a certificate – from entirely automated for a vanilla Apache installation through to the most complicated, entirely manual.
To see how difficult it was I decided to install a certificate for blighty.com, a domain on one of our very old webservers – one that was too old to install the letsencrypt tool itself. Fully manual! For a website on a different server!
I ran the letsencrypt tool, telling it I wanted a certificate for blighty.com. It gave me a the contents and location of a file to put on the blighty.com webserver – creating that required copying and pasting two commands from one shell window to another. Then it created and gave me the new certificate and key. I copied those across to the webserver and reloaded it’s configuration. And I have TLS!
This is going to be very simple to completely automate, so you could easily build it in to existing automation to create TLS protected action and tracking links for branded domains. Supporting thousands of TLS protected hostnames wouldn’t be difficult.
And how about using the certificates for things other than webservers? Mail servers, say? You do need a webserver to be live while you’re generating or renewing a certificate – but that’s actually easier to do for a host that doesn’t usually serve web pages than one that does. Once the certificate is generated you can use it for any service, including mail servers.
ACME-movie

What happened with the CBL false listings?

The CBL issued a statement and explanation for the false positives. Copying it here because there doesn’t seem to be a way to link directly to the statement on the CBL front page.

Increase in CBL listings

Update: As of Nov 24, 2015 11:18 Pacific, Spamhaus has rebuilt the zone and removed the broken entries. Expect the new data to propagate in 10 – 15 minutes. Delivery should be back to normal.
The CBL issued a statement, which I reposted for readers that find this post in the future. I think it’s important to remember there is a lot of malicious traffic out there and that malicious traffic affects all of us, even if we never see it.
Original Post from 10am pacific on Nov 24

Mid-morning west coast time, I started seeing an uptick in reports from many ESPs and marketers that they were getting listed on the XBL/CBL. Listings mentioned the kelihos spambot.

Tell me about your business model

I posted Friday about how most deliverability folks roll their eyes when a sender starts talking about their business model.
The irony is that one of the first things I do with a client is ask them to tell me about their business model and how email fits into their business plan. Once I know that, I can help them improve their email sending to meet the requirements of ISPs, blocklists and recipients.
While most deliverability people don’t care about your business model, for me it’s essential that I understand it. I want to hear about it, all the details. Tell me about what you’re doing and together we’ll craft a strategy to make email work for you in your unique situation.
We have one goal for every client: their email gets to the inbox. But no two clients have the same problems so we tailor our advice specifically for their unique situation. We don’t have a 3-ring binder that we read a standard answer from when clients ask for recommendations for their email strategy. We use our own knowledge of email and our history in the industry to craft unique solutions to deliverability problems.
Your business model is disruptive? Great! We can help you get those disruptive emails into their inbox.
You have a niche social platform that uses email as part of your growth strategy? We’ll make sure users and future users see your email in their inboxes.
You have a SaaS platform and you want customers to be able to use email to communicate with their customers? We’ll help you craft the right policy for your business.
You’re a retail company and struggle to reach the inbox consistently? We’ve helped dozens of companies navigate email challenges. We’ve helped clients figure out how to effectively capture addresses at point of sale in brick and mortars. We’ve helped clients restructure their entire data flow.
We can help you too.
You bring us your business model and we’ll create a comprehensive strategy that gets your email into the inbox. What’s more, we’ll help you understand what factors relate to inbox delivery and train you how to handle most issues on your own. Once we’ve got you set up, a process that takes 3 – 6 months, you have everything you need to run an email program. Even better, when those rare, complicated issues come up we’ve got your back and can get your emails delivering to the inbox again.

Dealing with blocklists, deliverability and abuse people

There are a lot of things all of us in the deliverability, abuse and blocklist space have heard, over and over and over again. They’re so common they’re running jokes in the industry. These phrases are used by spammers, but a lot of non-spammers seem to use them as well.
The most famous is probably “I’m sure they’ll unblock me if I can just explain my business model.” Trust me, the folks blocking your mail don’t want to hear about your business model. They just want you to stop doing whatever it is you’re doing. In fact, I’m one of the few people in the space who actually wants to hear about your business model – so I can help you reach your goals without doing things that get you blocked.
A few months ago, after getting off yet another phone call where I talked clients down from explaining their business model to Spamhaus, I put together list of phrases that senders really shouldn’t use when talking to their ESP, a blocklist provider or an abuse desk. I posted it to a closed list and one of the participants put it together into a bingo card.

A lot of these statements are valid marketing and business statements. But the folks responsible for blocking mail don’t really care. They just want their users to be happy with the mail they receive.

Thoughts on SenderScore

Kevin Senne posted over on the Oracle blog about how we need to stop caring about SenderScore and why it’s not as useful a metric as it used to be.
I can’t argue with anything he’s said. I think there is way too much focus on IP reputation and SenderScore. There’s so much more to deliverability than just one or two factors.
In fact, if you’ve been to any of my recent webinars or talks you will probably have seen some version of this image in my slides:

Basically, just because you have a great SenderScore doesn’t mean you’re going to have good delivery. Likewise, having a poor SenderScore doesn’t mean your mail is destined to be undelivered.
I tell clients, and people who ask about SenderScore that it reflects the data that Return Path gets, run through their proprietary algorithms to come up with a score. And that score is relevant for those ISPs that pay attention to it. But most ISPs make the deliver or not deliver decision based on their own internal data, not on the IPs SenderScore.

When did the reject happen?

Earlier today I approved a comment from Mike on a post about problems at AOL from 2012. The part of the comment that caught my attention:

DOD breaks links in .mil clients

The Department of Defense is breaking HTML links in mail to .mil domains. This is part of the DoD’s attempt to curtail phishing.

Filter complexity

During the Q&A last week, I mentioned an example of a type of filter trying to demonstrate how complex the filters are. There was some confusion about what I was saying, so I thought I’d write a blog post explaining this.

Thanks for the great session

I had a great time answering questions at the 2015 All About eMail Virtual Conference & Expo today. Thanks so much to everyone who participated and asked questions. They were great and I’m sorry we didn’t have more time.
I did get some questions on twitter (@wise_laura) afterwards. One was about an example I gave to explain how filters are complex. There have been rumors going around recently that Gmail is filtering mail with more than 3 URLs in it. Let me just say right now THIS IS NOT TRUE emails with more than 3 URLs in them are being delivered just fine to Gmail.
There is a situation involving the number (and type) of URLs that I think are a useful example of the filter complexity happening at some places, like Gmail. I started working on it, but don’t quite have time to finish it today, but will keep working on and it should go up in the next day or so.
Thanks again to everyone who joined the session. You asked some great questions and I had fun answering them.