Recent Posts

Who's publishing DMARC?

DMARC is a way for a domain owner to say “If you see this domain in a From: header and it’s not been sent straight from us, please don’t deliver the mail”. If a domain is only used for bulk and transactional mail, it can mitigate a subset of phishing attacks without causing too many problems for legitimate email.
In other cases, it can cause significant problems. Some of those problems impact discussion lists, but others cause problems for ESPs servicing small companies and individuals. ESP customers use their email addresses in the From: field; if they’re a small customer using the email address provided by their ISP, and that ISP publishes a DMARC record with p=reject, a large chunk of the mail they’re sending will bounce. When that happens recipients will stop getting their email, they’ll be removed from the mailing list due to bounces, and there’s some risk of blocks being raised against the sending IP address.
Because of that, it’s good to be able to see what consumer ISPs are doing with DMARC.
I’ve created a tool at dmarc.wordtothewise.com that regularly checks a list of large consumer ISPs and webmail providers and sees what DMARC records they’re publishing.
There are two main variants of DMARC records.
One is policy “reject” – meaning that mail that isn’t authenticated (or for which authentication has been broken in transit) will likely be rejected.
The other is policy “none” – meaning that the ISP publishing the record doesn’t want recipients to change their delivery decisions, but are asking for feedback about their mailstream, and how much of it fails authentication. That can mean that the ISP is evaluating whether or not to publish p=REJECT, or is in the process of deploying p=REJECT. Or it can just mean that they’re using DMARC to monitor where mail using their domain in the From: address is being sent from. There’s no way to tell which is the case unless they’ve made an announcement about their plans.
Hopefully this will be a useful tool to monitor DMARC deployment by consumer ISPs, and to help diagnose delivery problems that may be caused by DMARC.

Read More

Cryptography with Alice and Bob

Untrusted Communication Channels
This is a story about Alice and Bob.
Alice wants to send a private message to Bob, and the only easy way they have to communicate is via postal mail.
closedletter
Unfortunately, Alice is pretty sure that the postman is reading the mail she sends.
openletter
That makes Alice sad, so she decides to find a way to send messages to Bob without anyone else being able to read them.
Symmetric-Key Encryption
Alice decides to put the message inside a lockbox, then mail the box to Bob. She buys a lockbox and two identical keys to open it. But then she realizes she can’t send the key to open the box to Bob via mail, as the mailman might open that package and take a copy of the key.
Instead, Alice arranges to meet Bob at a nearby bar to give him one of the keys. It’s inconvenient, but she only has to do it once.
lockstore
After Alice gets home she uses her key to lock her message into the lockbox.
shared1Then she sends the lockbox to Bob. The mailman could look at the outside, or even throw the box away so Bob doesn’t get the message – but there’s no way he can read the message, as he has no way of opening the lockbox.
shared2
Bob can use his identical key to unlock the lockbox and read the message.
shared3
This works well, and now that Alice and Bob have identical keys Bob can use the same method to securely reply.
Meeting at a bar to exchange keys is inconvenient, though. It gets even more inconvenient when Alice and Bob are on opposite sides of an ocean.
Public-Key Encryption
This time, Alice and Bob don’t ever need to meet. First Bob buys a padlock and matching key.
public1
Then Bob mails the (unlocked) padlock to Alice, keeping the key safe.
public2
Alice buys a simple lockbox that closes with a padlock, and puts her message in it.
public3
Then she locks it with Bob’s padlock, and mails it to Bob.
public4
She knows that the mailman can’t read the message, as he has no way of opening the padlock. When Bob receives the lockbox he can open it with his key, and read the message.
public5
This only works to send messages in one direction, but Alice could buy a blue padlock and key and mail the padlock to Bob so that he can reply.
Or, instead of sending a message in the padlock-secured lockbox, Alice could send Bob one of a pair of identical keys.
publichared
Then Alice and Bob can send messages back and forth in their symmetric-key lockbox, as they did in the first example.
shared2
This is how real world public-key encryption is often done.

Read More

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.
pgp
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.

Read More

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.

Read More

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)
mailapprules

Read More

Dealing with compromised user accounts

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

Read More

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?

Read More

IP Reputation

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

Read More

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.
 

Read More

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.

Read More
Categories
Tags