Recent Posts

TLS and Encryption

Yesterday I talked about STARTTLS deployment, and how it was a good thing to support to help protect the privacy of your recipients.
STARTTLS is just one aspect of protecting email from eavesdropping; encrypting traffic as the mail is being sent or read and encrypting the message itself using PGP or S/MIME are others. This table shows what approaches protect messages at different stages of the messages life:
[table nl=”~”] Compromise point,SUBMIT~+IMAPS,TLS,PGP /~SMIME
Sender’s computer as mail is sent,,,
Sender’s computer later,,,[icon name=check-square] Sender’s network,[icon name=check-square],,[icon name=check-square] Sender’s ISP,,,[icon name=check-square] Global Internet (passive),,[icon name=check-square],[icon name=check-square] Global Internet (active),,[icon name=question-circle],[icon name=check-square] Global Internet (later),,[icon name=question-circle],[icon name=check-square] 3rd party mail services,,,[icon name=check-square] Recipient’s ISP,,,[icon name=check-square] Recipient’s network,[icon name=check-square],,[icon name=check-square] Recipient’s computer as mail is read,,,
Recipient’s computer later,,,[icon name=check-square] [/table] You can see that if you’re sending really sensitive data, you should be encrypting the entire message with PGP or S/MIME (or not sending the message via email at all). Doing so will protect the content of the mail against pretty most sorts of attack, but is pretty intrusive for the sender and recipient so can’t really be used without prior agreement with the recipient.
The other approaches will make some sorts of passive surveillance much more difficult, though.
Encrypting the connection a user uses to send mail ([rfc 6409]using the SUBMIT protocol[/rfc]) and to read mail ([rfc 2595]using TLS to protect IMAP or POP3[/rfc]) will protect against passive sniffing when the user is on possibly hostile network, such as public wifi or an employers network. That’s an easy place to try and sniff traffic, and if that traffic isn’t protected an attacker can not only read someone’s email, they can steal their credentials and cause all sorts of havoc. All general purpose mail clients and all ISPs support encryption here, so it’s almost universally used.
STARTTLS use with SMTP is all about protecting email traffic when it’s being sent between ISPs – both between the sender’s ISP and the recipient’s and also between any 3rd party mail services (outsourced spam filtering, mailing list providers, vanity domain fowarders, etc.).
I’ve listed three different sorts of attack on that inter-ISP traffic – passive, active and “later”.
A passive attack is where the attacker has the ability to listen to bytes as they go by, but isn’t able to modify or intercept them. While you might think of this as something a nation state would do, via secret agreements with backbone providers or high-tech fiber optic cable taps, there are ways a smaller attacker might be able to compromise an intermediate router and tap that traffic with little risk of detection. Deploying any sort of STARTTLS will protect against this, even if it’s misconfigured, using expired certificates or even just the default setup of a newly deployed mailserver. Facebook describe these weaker forms of STARTTLS as “opportunistic” in their survey – it’s not perfect, but it’s a lot better than nothing.
An active attack is one where the attacker has the ability to intercept and modify traffic between the two ISPs. This seems like it would be harder to do than a passive attack, but it’s often easier, though not as stealthy. Once that’s done, the attacker can pretend to be the recipient ISP and have full access to read, modify or discard messages. To protect against this sort of attack TLS needs to be used not just to encrypt the traffic in-flight, but also to allow the sender to validate that the mailserver they’re talking to really is who they think it is. This is what Facebook describe as “strict” – it requires that the mailserver have a valid certificate, issued by a legitimate certification authority for the domain that the mail is being sent to.
What about “later”? It’s easy to imagine a case where an attacker has been passively monitoring and recording encrypted traffic for a while, and then later they manage to acquire the encryption keys that were used (by, for example, issuing a subpoena to the recipient ISP, or using a compromise to rip them out of your servers memory). With many forms of encryption once you have those private keys it’s possible to decrypt all the traffic you’ve already captured. There are a few algorithms, though, that have what’s known as perfect forward secrecy – knowing the private keys that were used at the time the mail was transferred doesn’t allow you to decrypt them at a later time. If you’re concerned about the privacy of your messages, you should definitely read up on how to set that up.
All of these techniques are a great way to defend against ubiquitous or casual attempts to read your messages, but none of them are proof against a determined attacker. If all else fails, there’s always a wrench attack.

Protect your email with TLS

You probably use TLS hundreds of times a day. If you don’t recognize the term, you might know it better by it’s older name, SSL.
TLS is what protects your data in transit whenever you go to Google, or Yahoo or even this blog. The little padlock in your browser address bar tells you that your browser has used the TLS protocol to do two things. First, it’s decided that the server you’re connecting to really is operated by Google, or Yahoo or us – you’re (probably) not having your session intercepted by someone in the middle between you and the webserver, either to read your traffic or modify it en-route. Second, it is encrypting all the traffic between you and the webserver, so that it can’t be passively monitored while in transit. Because of concerns about ubiquitous surveillance many websites – including ours – are moving to use TLS for everything, not just for protecting a login page or a credit card number.
That’s great for the web, but how does it apply to email? One place it’s used is for connections between your mail client and your local mailserver – sending mail to the smarthost via [rfc 4409]SUBMIT[/rfc] and fetching mail using [rfc 2595]IMAP or POP3[/rfc] almost always use TLS. That protects the privacy of your messages between you and your ISP and also protects the username and password you use to authenticate with.
Mail traveling between ISPs didn’t used to be encrypted “on the wire” , but about 15 years ago [rfc 3207]an extension to SMTP was proposed[/rfc] that would allow ISPs to negotiate during each session whether they should encrypt it or not. This extension, often referred to as STARTTLS after the command it uses, allows gradual rollout of encryption of mail traffic between ISPs without requiring any sort of flag day. A mailserver that supports STARTTLS will tell everyone who connects to it “Hey! I support STARTTLS!”. When a smarthost that also supports it connects to that mailserver it will go “Great! I support STARTTLS too! Lets do this!” and convert the plain text SMTP session into an encrypted session protected by TLS.
Fifteen years seems like a long period in Internet time, but non-intrusive protocol changes can take a long time to deploy. Facebook Engineering have done the work to see how that deployment is going with their survey of the current state of SMTP STARTTLS deployment. The results are really quite positive – over three quarters of the mailservers they sent mail to supported STARTTLS, covering nearly 60% of their users. That’s definitely enough to make supporting STARTTLS worthwhile.
More about TLS and encryption tomorrow.

Spam is not a valid marketing strategy

This seems like an attempt to create the next big viral marketing campaign. It’s just spam, though, and not even good spam. There’s nothing about a random “click here” that will entice me to click on it.
Scammers? Spammers? Whoever Ryann Rasmussen at HighSpeedInternet is, she might want to rethink her marketing strategy. It looks more like an infection attempt than anything else.

I guess we can say that their mail made an impression, a very negative impression. There is no website at http://highspeedinternet.com. The whois record for highspeedinternet.com is behind domains by proxy. The mail violates CAN SPAM. The address was scraped off our website.
Not all spammers are dodgy Russians. Some spammers are from Utah.

SMTP Level Rejections

While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet.
At initial connection
Dropped or failed connection:

Using Google to taunt coworkers

Happy Friday, all. This has been a rough week for so many people, I thought we needed a little humor.
From Tim Norton (@norton_tim) on Twitter.

IP reputation and email delivery

IP reputation is a measure of how much wanted mail a particular IP address sends. This wanted mail is measured as a portion of the total email sent from that IP. Initially IP reputation was really the be all and end all of reputation, there was no real good way to authenticate a domain or a from address. Many ISPs built complex IP reputation models to evaluate mail based on the IP that sent the mail.
These IP reputation models were the best we had, but there were a lot of ways for spammers to game the system. Some spammers would create lots of accounts at ISPs and use them to open and interact with mail. Other spammers would trickle their mail out over hundreds or thousands of IPs in the hopes of diluting the badness enough to get to the inbox. Through it all they kept trying to get mail out through reputable ESPs, either by posing as legitimate customers or compromising servers.
These things worked for a while, but the ISPs started looking harder at the recipient pool in order to figure out if the interactions were real or not. They started looking at the total amount of identical mail coming from multiple IP addresses. The ISPs couldn’t rely on IP reputation so they started to dig down and get into content based filtering.
As the ISPs got better at identifying content and filtering on factors other than source IP, the importance of the IP address on inbox delivery changed. No longer was it good enough to have a high reputation IP sending mail.
These days your IP reputation dictates how fast you can send mail to a particular ISP. But a high reputation IP isn’t sufficient to get all the mail in the inbox. It’s really content that drives the inbox / bulk folder decisions these days.

Generally IPs that the ISP has not seen email traffic from before start out with a slight negative reputation. This is because most new IPs are actually infected machines. The negative reputation translates to rate limiting. The rate limiting minimizes people getting spam while the ISP works out if this is a real sender or a spammer.
Some ISPs put mail in the inbox and bulk foldering during the whitelisting process. In this case what they’re doing is seeing if your recipients care enough about your mail to look for it in the bulk folder. If they do, and they mark the mail as “not spam” then this feeds back to the sender reputation and the IP reputation.
If you’re seeing a lot of bulk foldering of mail, it’s unlikely there’s anything IP reputation based to do. Instead of worrying about IP reputation, focus instead on the content of the mail and see what you may need to do to improve the reputation of the domains and URLs (or landing pages) in the emails.

Thoughts on Gmail and the inbox

Over the last few months more and more marketers are finding their primary delivery challenge is the Gmail inbox. I’ve been thinking about why Gmail might be such a challenge for marketers. Certainly I have gotten a lot of calls from people struggling to figure out how to get into the Gmail inbox. I’ve also seen aggressive domain based filtering from Gmail, where any mention of a particular domain results in mail going to the bulk folder.
It’s one of those things that’s a challenge, because in most of these cases there isn’t one cause for bulk foldering. Instead there’s a whole host of things that are individually very small but taken together convince Gmail that the mail doesn’t need to be in the inbox.
A pattern that I’m starting to see is that Gmail is taking a more holistic look at all the mail from a sender. If the mail is connected to an organization, all that mail is measured as part of their delivery decision making. This is hurting some ESPs and bulk senders. I’ve had multiple ESPs contact me in the last 6 months looking for help because all their customer emails are going to bulk folder.
Gmail’s filtering is extremely aggressive. From my perspective it always has been. I did get an invite for a Gmail account way back in the day. I moved a couple mailing lists over to that account to test it with some volume and discussion lists. I gave up not long after because no matter what I did I couldn’t get gmail to put all the mail from that list into the tag I had set up for it. Inevitably some mail from some certain people would end up in my spam folder.
Gmail has gotten better, now they will let you override their filters but give you a big warning that the message would have been delivered to spam otherwise.

What are mailers to do? Right now I don’t have a good answer. Sending mail people want is still good advice for individual senders. But I am not sure what can be done about this ESP wide filtering that I’m starting to see. It’s possible Gmail is monitoring all the mail from a particular sender or ESP and applying a “source network” score. Networks letting customers send mail Gmail doesn’t like (such as affiliate mail or payday mail, things they mentioned specifically at M³AAWG) are having all their customers affected.
I suspect this means that ESPs seeing problems across their customer base are going to have to work harder to police their customers and remove problematic mail streams completely. Hopefully, ESPs that can get on the Gmail FBL can identify the problem customers faster before those customers tank mail for all their senders.

Spam is not a moral judgement

Mention an email is spam to some senders and watch them dance around trying to explain all the ways they aren’t spammers. At some point, calling an email spam seems to have gone from a statement of fact into some sort of moral judgement on the sender. But calling an email spam is not a moral judgement. It’s just a statement of what a particular recipient thinks of an email.
There are lots of reasons mail can be blocked and not all those reasons are spam related. Sometimes it’s a policy based rejection. Mailbox providers publishing a DMARC record with a reject policy caused a lot of mail to bounce, but none of that was because that user (or that mailing list) was sending spam. Most cable companies prohibit customers from running mail servers on their cable connection and mail from those companies is widely rejected, but that doesn’t mean the mail is spam.
Sometimes a block is because some of the mail is being sent to people who didn’t ask for it or are complaining about it. This doesn’t make the sender a bad person. It doesn’t make the sending company bad. It just means that there is some issue with a part of the marketing program that need to be addressed.
The biggest problem I see is some senders get so invested in convincing receivers, delivery experts and filtering companies that they’re not spammers, that they miss actually fixing the problem. They are so worried that someone might think they’re spammers, they don’t actually listen to what’s being said by the blocking organization, or by their ISP or by their ESP.
Calling email spam isn’t a moral judgement. But, if too many people call a particular email spam, it’s going to be challenging to get that mail to the inbox. Instead of arguing with those people, and the filters that listen to them, a better use of time and energy is fixing the reasons people aren’t liking your email.

More from Gmail

Campaign Monitor has an interview with Gmail looking at how to get mail to the Gmail inbox. It’s a great article and I think everyone should go read it.
One of the most important things it talks about is how complex filters are.

April: The month in email

April was a big month of changes in the email world, and here at Word to the Wise as we launched our new site, blog and logo.
DMARC
The big story this month has been DMARC, which started with a policy change Yahoo made on April 4 updating their DMARC policy from “report” to “reject”. We began our coverage with a brief DMARC primer to explain the basics around these policy statements and why senders are moving in this direction. We shared some example bounces due to Yahoo’s p=reject, and talked about how to fix discussion lists to work with the new Yahoo policy. We gathered some pointers to other articles worth reading on the Yahoo DMARC situation, and suggested some options for dealing with DMARC for mail intermediaries. Yahoo issued a statement about this on April 11th, explaining that it had been highly effective in reducing spoofed email. We also noted a great writeup on the situation from Christine at ReturnPath. On April 22nd, AOL also announced a DMARC p=reject record. We talked a bit about who might be next (Gmail?) and discussed how Comcast chose to implement DMARC policies, using p=reject not for user email, but only for the domains they use to communicate directly with customers. We expect to see more discussion and policy changes over the next few weeks, so stay tuned.
Spamtraps
We wrote three posts in our continuing discussion about spamtraps. The first was in response to a webinar from the DMA and EEC, where we talked about how different kinds of traps are used in different ways, and, again, how spamtraps are just a symptom of a larger problem. Following that, we wrote more about some ongoing debate on traps as we continued to point out that each trap represents a lost opportunity for marketers to connect with customers, which is really where we hope email program managers will focus. And finally, we tried to put some myths about typo traps to rest. As I mentioned in that last post, I feel like I’m repeating myself over and over again, but I want to make sure that people get good information about how these tools are used and misused.
Security
We started the month by saying “Security has to become a bigger priority for companies” and indeed, the internet continued to see security breaches in April, including the very serious Heartbleed vulnerability in SSL. In the email world, AOL experienced a compromise, which contributed to some of the DMARC policy changes we discussed above. In a followup post, we talked about how these breaches appear to be escalating. Again, we expect to hear more about this in the next weeks and months.
Best Practices
Ending on a positive note, we had a few posts about best practices and some email basics. We started with a pointer to Al Iverson’s post on masking whois info and why not to do it. Steve wrote up a comprehensive post with everything you ever wanted to know about the From header and RFC5322. I talked about how companies ignore opt-outs, and why they shouldn’t. I shared a really good example of a third-party email message, and also talked about message volume. And finally, we talked about how and why we warm up IP addresses.
Let us know if there’s anything you’d like to hear more about in May!