Recent Posts

Spot the unsub

A new game! Spot the unsub! Our first challenge is the footer from a major software company. How long does it take for you to to find the unsub link?

What’s even more annoying is that I never actually subscribed to mail from this company. A few years ago I was doing some work for them and they required I set up an account on their cloud service so they could share docs with me. Last month, they started emailing me as “a customer.” Yeah. No.

The more things change

I was doing some research about the evolution of the this-is-spam button for a blog article. In the middle of it, I found an old NY Times report about spam from 2003.

Yahoo FBL problems

Multiple ESPs are reporting that the volume of Yahoo! FBL reports have slowed to a trickle over the last 24 or so hours. While we don’t know exactly what is going on yet, or if it’s on track for being fixed, there does seem to be a problem.
There has been some ongoing maintenance issues with the Yahoo! FBL, where requests for updates and changes weren’t being handled in a timely fashion. Informed speculation was the resources needed to fix the FBL modification weren’t available. The interesting question is if Y! will commit the resources to fix the FBL. I could make arguments either way. But Yahoo! gets the benefit of the this-is-spam button whether or not they send a complaint back to the sender.
5/21 5pm: Both Yahoo and Return Path (who administer the Y! FBL) are aware of the problem and are working on it.
5/21 6:30pm: Reports are flowing again according to multiple sources.

Email templates using Grunt

A Grunt workflow for designing and testing HTML email templates with SCSS.

It's about the spam

Tell someone they have hit a spamtrap and they go through a typical reaction cycle.
Denial: I didn’t hit a trap! I only send opt-in mail. There must be some mistake. I’m a legitimate company, not a spammer!
Anger: What do you mean that I can’t send mail until I’ve fixed the problem? There is no problem! You can’t stop me from mailing. I’m following the law. My mail is important. I’ll sue.
Bargaining: What if I just send mail to some recipients? What if I hire an email hygiene company to remove traps from my list?
Acceptance: What can I do to make sure the people I’m mailing actually want to be on my list?
Overall, my problem with the focus on spamtraps (and complaints to a lesser extent) is that these metrics are proxies. Spamtraps are a way to objectively monitor incoming email. Mail sent to spamtraps is, demonstrably, sent without permission of the address owner. This doesn’t mean all mail from the same source is spam, but there is proof at least some of the mail is spam.
If there is enough bad mail on that list, then reworking the subscription process may be necessary to fix delivery.

Emoji – older than you think

It might just be random 17th Century punctuation, but this poem from 1648 certainly seems to be using a smiley face emoji.
(OK, it’s probably not intentional, but it’s lovely intersection of the emoji and the word.)

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: