Recent Posts

Cryptography and Email

A decade or so ago it was fairly rare for cryptography and email technology to intersect – there was S/MIME (which I’ve seen described as having “more implementations than users”) and PGP, which was mostly known for adding inscrutable blocks of text to mail and for some interesting political fallout, but not much else.

That’s changing, though. Authentication and privacy have been the focus of much of the development around email for the past few years, and cryptography, specifically public-key cryptography, is the tool of choice.
DKIM uses public-key cryptography to let the author (or their ESP, or anyone else) attach their identity to the message in a way that’s almost impossible to forge. That lets the recipient make informed decisions about whether to deliver the email or not.
DKIM relies on DNS to distribute it’s public keys, so if you can interfere with DNS, you can compromise DKIM. More than that, if you can compromise DNS you can break many security processes – interfering with DNS is an early part of many attacks. DNSSEC (Domain Name System Security Extensions) lets you be more confident that the results you get back from a DNS query are valid. It’s all based on public-key cryptography. It’s taken a long time to deploy, but is gaining steam.
TLS has escaped from the web, and is used in several places in email. For end users it protects their email (and their passwords) as they send mail via their smarthost or fetch it from their IMAP server. More recently, though, it’s begun to be used “opportunistically” to protect mail as it travels between servers – more than half of the mail gmail sees is protected in transit. Again, public-key cryptography. Perhaps you don’t care about the privacy of the mail you’re sending, but the recipient ISP may. Google already give better search ranking for web pages served over TLS – I wouldn’t be surprised if they started to give preferential treatment to email delivered via TLS.
The IETF is beginning to discuss end-to-end encryption of mail, to protect mail against interception and traffic analysis. I’m not sure exactly where it’s going to end up, but I’m sure the end product will be cobbled together using, yes, public-key cryptography. There are existing approaches that work, such as S/MIME and PGP, but they’re fairly user-hostile. Attempts to package them in a more user-friendly manner have mostly failed so far, sometimes spectacularly. (Hushmail sacrificed end-to-end security for user convenience, while Lavabit had similar problems and poor legal advice).
Not directly email-related, but after the flurry of ESP client account breaches a lot of people got very interested in two-factor authentication for their users. TOTP (Time-Based One-Time Passwords) – as implemented by SecureID and Google Authenticator, amongst many others – is the most commonly used method. It’s based on public-key cryptography. (And it’s reasonably easy to integrate into services you offer).
Lots of the other internet infrastructure you’re relying on (BGP, syn cookies, VPNs, IPsec, https, anything where the manual mentions “certificate” or “key” …) rely on cryptography to work reliably. Knowing a little about how cryptography works can help you understand all of this infrastructure and avoid problems with it. If you’re already a cryptography ninja none of this will be a surprise – but if you’re not, I’m going to try and explain some of the concepts tomorrow.

Talking about deliverability

Next Tuesday, September 23, I’ll be speaking about deliverability at a webinar sponsored by Message Systems and presented by the American Marketing Association.
Registration is open to all, so if you’re interested in hearing some of my opinions about deliverability past, present and future, sign up.

Make Mail.app work for you

Mark Nottingham (@mnot) posted a good idea to twitter:

Highlight e-mails that your MTA receives with TLS. Make sure to include your mail server’s name in the value (here to the left of what’s shown)
Read More

Dealing with compromised user accounts

M³AAWG is on a roll lately with published documents. They recently released the Compromised User ID Best Practices (pdf link).

Content based filtering

Content filtering is often hard to explain to people, and I’m not sure I’ve yet come up with a good way to explain it.
A lot of people think content reputation is about specific words in the message. The traditional content explanation is that words like “Free” or too many exclamation points in the subject line are bad and will be filtered. But it’s not the words that are the issue it’s that the words are often found in spam. These days filters are a lot smarter than to just look at individual words, they look at the overall context of the message.
ISP_tolerances
Even when we’re talking content filters, the content is just a way to identify mail that might cause problems. Those problems are evaluated the same way IP reputation is measured: complaints, engagement, bad addresses. But there’s a lot more to content filtering than just the engagement piece. What else is part of content evaluation?

IP Reputation

A throwback post from a few years ago on IP reputation.

Who didn't invent email?

Who didn’t invent email? Shiva Ayyadurai.
He’s not the only one – I didn’t invent email either, nor did Abraham Lincoln, Boadicea or Tim Berners-Lee. So why mention Shiva?
He claims that in 1978 when he was 14, he took some courses in programming. His mum worked for the University of Medicine and Dentistry of New Jersey, and one of her colleagues challenged him to write an electronic mail system. And he did just that, creating a basic messaging system in FORTRAN, based on the existing paper memo format, ending up with a non-networked electronic mail system with similar functionality to mainstream applications that were in use well over a decade earlier.
That’s pretty impressive, and is the sort of thing that’ll look good on a college application form. (When I was 13 I designed and implemented a chassis dynamometer management unit that Shell’s research division used to test fuel and lube oil performance over virtual driving tracks – dozens of pages of 6502 assembly code, and you can be sure I put that on my college application form).
Some years later, in 1982, Shiva applied for and was granted a certificate of copyright registration on that piece of software. A copyright is not a patent – it recognizes and protects the expression of the work, not the idea underlying the work. There’s no real bar for copyright, other than it being a piece of work you created yourself – I automatically own copyright to anything I create, including software I’ve written and this blog post. Registering a copyright on a work, whether it be software or anything else, is a trivial exercise in bureaucracy – you fill in a form, you pay a registration fee, it gets rubber stamped. What is protected by the copyright is the work – in this case the software source code – itself, not the ideas, not the name of the package, nothing else. (I have copyright on my software package, Abacus. That doesn’t mean that I invented the Abacus.)
Meanwhile, Shiva moved into email marketing, founded a small ESP, and seems to be doing quite nicely (although a journalist who looked can’t find much evidence of the ESP being successful, or even existing, other than a lawsuit it filed against IBM and American Express for misappropriation of trade secrets in 2005).
Back in 2011, though, things started to get weird. Shiva started to use this copyright filing, and the fact that he used the title “EMAIL” on the filing, to support a claim that he was “the inventor of email”. It’s a compelling human interest / tech story to journalists whose knowledge of email and internet history is vague, so it got quite a bit of coverage.
(Shiva makes an image of his copyright certificate available: http://www.vashiva.com/images/vashiva_patent3_enl.jpg. Note that the URL describes it as a “patent”, rather than a copyright filing.)
It was quickly debunked. It didn’t pass the sniff test. Technical blogs started asking how the Washington Post and other press had fallen for this. The Washington Post clarified that pretty much all the significant claims in the original article were untrue.
It didn’t go away, though. Two-and-a-half years later, there’s a series of articles in the Huffington Post, pitching the same story, this time with a few unpleasant twists in it’s approach. It’s got a glossy infographic, filled with provably false claims. It has the feel of a professional PR campaign, rather than an article written by a reporter. Sure enough, it’s written by Larry Weber, a high powered PR guy (CEO of RacepointGlobal – who “build the right influencer relationships for your brand” – and CEO of Weber Public Relations Worldwide). There are at least five article in the series, all written by different people, but having oddly similar phrasing.
Shiva’s ESP, EchoMail, and their current branding is based around his (false) claim to be the “Inventor of Email”, so there’s clearly money as well as ego at stake. Neither Larry Weber nor the Huffington Post mentioned that Larry Weber is also on the board of EchoMail.
So we’re going through the debunking process again. I was going to write more, but others are way ahead of me.

Changing your email address

Over at Mediapost, Loren McDonald talks about how hard it’s been to change his email address when his employer got bought out.

August 2014: The Month in Email

Isn’t August the month where things are supposed to slow down? We’re still waiting for that to happen around here… it’s been great to be busy, but we’re hoping to continue to carve out more time for blogging as we move into the fall.
August
As usual, we reported on a mix of industry trends and news, the persistence of spam, and did a deep dive into an interesting technical topic. Let’s start there: Steve wrote a post explaining Asynchronous Bounces (yes, it’s a GNFAB), with some examples of how they’re used and how they can cause operational problems.
In industry news, we did a roundup post of some Gmail changes and a followup post on security issues with non-Latin characters in addresses. We also celebrated the long-awaited release of a wonderful resource from MAAWG that I am very proud to have helped author, the white paper Help! I’m on a Blocklist! (PDF link). We receive dozens of these calls every week, and though we are always happy to help people solve urgent delivery crises, we spend most of our consulting time and attention working with people to build sustainable email programs, so this document is a great “self-service” resource for people looking to troubleshoot blocklist issues on their own.
In other industry and MAAWG-related news, we noted that the nomination period for the J.D. Falk award has opened (you have just a few more days, procrastinators) and took a moment to reminisce about our friend J.D. and his incredible contributions to the field.
On the topic of creating, sending, and reading more attractive email, we posted some resources from Mailchimp and crowdsourcing templates from Send With Us. We also incorrectly reported on a not-actually-new interface from AOL, Alto. Interesting to note that there’s been so little followup from AOL (and almost no post-launch coverage) in the two years since launch.
We also touched on a few myths: email saves trees and low complaint volume is good.
And finally, in November of 2013, I unsubscribed from every possible email I received on a specific account. I followed up on that briefly in a Part 2 post, and this month went back and wrote a Part 3 followup. Spoiler alert: spam is still a problem. Of course, we got some comments that we were probably doing it wrong, so Unsubscribe Barbie showed up to add her thoughts. We try not to be snarky around here, but sometimes we just don’t try very hard.

The origins of network email

The history of long distance communication is a fascinating, and huge, subject. I’m going to focus just on the history of network email – otherwise I’m going to get distracted by AUTODIN and semaphore and facsimile and all sorts of other telegraphy.

Electronic messaging between users on the same timesharing computer was developed fairly soon after time-sharing computer systems were available, beginning around 1965 – including both instant messaging and mail. I’m interested in network mail, though, so we need to skip forward a few years.
You need a network. And a community.
Around 1968 the initial plans for “ARPANET”, a network to link the various ARPA-funded computers together were underway. Local mail between users on the same system was already a significant part of the nascent community.