Recent Posts

The true facts of spam traps and typo traps

I’m seeing an increase in the number of articles stating wildly wrong things about spam traps. Some have started claiming that typo traps are new. Or that typo traps are newly used by Spamhaus. These claims make for great copy, I guess. Wild claims about how the evil anti-commerce self-appointed internet police are actively trying to trap marketers get clicks. These claims also reinforce the martyr complex some senders have and gives them something to commiserate about over drinks at the next email conference.
I strongly recommend ignoring any article that claims Spamhaus started using typo traps in December 2012. In fact, you can immediately dismiss absolutely everything they have to say. They are wrong and have proven they can’t be bothered to do any fact checking.
I can’t figure out why so many people repeat the same false statements over and over and over again. They’re wrong, and no amount of explaining the truth seems to make any difference. I went looking for evidence.
First, I asked on Facebook. A bunch of my contacts on Facebook have have been running spam traps for a long time. Multiple people commented that they, personally, have been using typos to track spam since the late ’90s. These typos were on both the right hand side of the @ sign (the domain side) but also on the left hand side of the @ sign (the username).
Then, I looked through my archives of one of the anti-spam mailing lists and I see a Spamhaus volunteer mentioning that he had already been using typo traps in 2007. I asked him about this and he pointed out these are some of his older traps and had been around for many years before that mention.
Of course, we’ve written about typo domains used by an anti-spam group to catch spam.
The truth is, typo traps are not new and they’re not a new set of traps for Spamhaus. I’ve talked about traps over and over again. But I’m seeing more and more articles pop up that make verifiably wrong statements about spam traps. Here are a few facts about spam traps.

DMARC and organizations

Comcast recently published a statement on DMARC over on their postmaster page. The short version is that Comcast is publishing a DMARC record, but has no current intentions to publish a p=reject policy for Comcast user email. Comcast will be publishing a p=reject for some of their domains that they use exclusively to communicate with customers, like billing notices and security notices.
Comcast does point out that Yahoo! and AOL’s usage of p=reject is “not common usage.”
This is something a lot of people have been arguing loudly about on various mail operations lists and network lists. DMARC is about organizational identity. In fact, I was contacted about my DMARC primer and told that I didn’t mention that it’s not about domains, it’s about organizations.
The way I read the DMARC spec, it is all about organizational identity. The underlying theme being that the domain name is linked to a particular organization and everyone using email at that domain has some official relationship with that organization. I’ve always read the spec mentally replacing organization with corporate brand. This was for brands and organizations that strictly control how their domains are used, who can use those domains and how the mail is sent with those domains.
I never expected any mailbox provider or commercial ISP to publish a p=reject message as it would just break way too much of the way customers use email. And it did break a lot of legitimate and end user uses of email. Many organizations have had to scramble to update mailing list software to avoid bouncing users off the lists. Some of these upgrades have broken mailbox filters, forcing endusers to change how they manage their mailboxes.
Even organizations see challenges with a p=reject message and can have legitimate mail blocked. At M³AAWG 30 in San Francisco I was talking with some folks who have been actively deploying DMARC for organizations. From my point of view anyone who wants to publish a DMARC p=reject should spend at least 6 months monitoring DMARC failures to identify legitimate sources of email. The person I was talking to said he recommends a minimum of 12 months.
This is just an example of how difficult it is to capture all the legitimate sources of emails from a domain and effectively authenticate that mail. For a mailbox provider, I think it’s nearly impossible to capture all the legitimate uses of email and authenticate them.
It remains to be seen if the other mailbox providers imitate Yahoo! and AOL or if they push back against the use of DMARC reject policies at mailbox providers. Whatever the outcome, this is a significant shift in how email is used. And we’re all going to have to deal with the fallout of that.

AOL admits to security breach

According to Reuters AOL has admitted there was a breach of their network security that compromised 2% of their accounts. Users are being told to reset their passwords, and security questions.
AOL started investigating the attack after users started reporting an uptick in spam from aol.com addresses. This spam was using @aol.com addresses to send mail to addresses in that user’s address book.
According to the AOL mail team, they are still investigating the attack, but they do not believe financial information was compromised. Their statement reads in part:

Is gmail next?

I’m hearing hints that there are some malware or phishing links being sent out to gmail address books, “from” those gmail addresses. If that is what’s happening then it’s much the same thing as has been happening at Yahoo for a while, and AOL more recently, and that triggered their deployment of DMARC p=reject records.
It’s going to be interesting to see what happens over the next few days.
I’ve not seen any analysis of how the compromises happened at Yahoo and AOL – do they share a server-side (XSS?) security flaw, or is this a client-side compromise that affects many end users, and is just being targeted at freemail providers one at a time?
Does anyone have any technical details that go any deeper than #AOLHacked and #gmailhacked?

Why do we "warmup" IP addresses

IP address warmup is a big issue for anyone moving to a new IP address for sending.
I’m constantly being asked how to warm up an IP. My answer is always the same. There’s no right way to warm up an IP nor is there a specific formula that everyone should follow.
What warming up is about is introducing mail traffic to receiving spam filters in a way that lets the filter know this is a legitimate email stream. This means sending small but regular amounts of mail that recipients interact with. As the filters adjust to the amount of mail from that IP, more mail can be sent over that IP. Increase the mail volume over the next few weeks until the desired volume is reached.
There are a couple things to remember about warming up.

More on spam traps

A couple weeks ago I had a discussion with Ken Magill of the Magill Report about spam traps. He had moderated a webinar about spam traps and I publicly contradicted some of the statements made about spam traps. He contacted me and interviewed me for an updated article about traps for his newsletter. The next week he had a rebuttal from Dela Quist of Alchemy Worx, taking anti-spammers (and presumably me) to task for pointing out that some folks use typos as spam traps. This week, Derek Harding of Innovyx continues the discussion about traps and how they are a reality that senders need to deal with.
Spam traps are a reality and they’re not going away at any foreseeable point in the future. No entity that actually cares about blocking spam is going to give up the information that spam traps provide them. Not A Single One. They are some of the original tools in the filtering arsenal and they have proven their use and reliability for people trying to keep inboxes useable.
Dela focused on typos in his rebuttal to Ken, but typos aren’t the real issue. The real issue is that any address acquisition technique (and I do mean any) is subject to errors. Those errors end up directing mail at people who didn’t ask for it. If there are too many errors or mail to too many of the wrong addresses, that will result in delivery problems.
Yelling at the people monitoring the accuracy of your email marketing doesn’t make your marketing any better. It doesn’t stop mail from going to the wrong people. It doesn’t actually help anything.
My focus is on helping marketers market better. My focus is on helping folks sending email get that mail to the inboxes of people who want it. I don’t really care if my clients hit traps, traps are, as Derek said, “the canary in the coal mine.” What I really want is to make sure every person who asked for mail from my clients gets that mail. Every trap on the list? That is a lost sale, a lost touch, a lost opportunity. The traps are just the addresses we know are wrong. If there are traps on a list, then it is guaranteed there are deliverable addresses that belong to someone who is not a customer. This generally means two lost customers, the one who isn’t getting the mail they asked for and the one who is getting mail they never asked for.
Traps are a way to quantify missed opportunities, but they’re not the only missed opportunities. If mail is going to traps, it’s not going to your real customers. That is why marketers should care about traps.

AOL publishes a p=reject DMARC record

Yesterday I mentioned that there were reports of a compromise at AOL. While the details are hazy, what has been reported is that people’s address books were stolen. The reports suggest lots of people are getting mail from AOL addresses that they have received mail from in the past, but that mail is coming from non AOL servers. In an apparent effort to address this, AOL announced today they have published a p=reject DMARC record.
I expect this also means that AOL is now checking and listening to DMARC records on the inbound. During the discussions of who was checking DMARC during the Yahoo discussion, AOL was not one of the ISPs respecting DMARC policy statements. I’m not surprised. As more information started coming out about this compromise, I figured that the folks attacking Yahoo had moved on to AOL and that AOL’s response would be similar to Yahoo’s.
My prediction is that the attackers will be trying to get into Outlook.com and Gmail, and when they do, those ISPs will follow suit in publishing p=reject messages. For those of you wondering what DMARC is about, you can check out my DMARC primer.

AOL compromise

Lots of reports today of a security problem at AOL where accounts are sending spam, or are being spoofed in spam runs or something. Details are hazy, but there seems to be quite a bit of noise surrounding this incident. AOL hasn’t provided any information as of yet as to what is going on.

ReturnPath on DMARC+Yahoo

Over at ReturnPath Christine has an excellent non-technical summary of the DMARC+Yahoo situation, along with some solid recommendations for what actions you might take to avoid the operational problems it can cause.

Is volume a problem?

Volume in an of itself is not a problem. Companies sending mail people want can send multiple emails a day to every user. The volume isn’t a problem because the mail is wanted.
Many senders are confused and think volume is a filtering criteria. It’s not. Send all you want; just send it to people who actually want the mail.
A lot of companies in their growth phase find they do have delivery problems as their volume ramps up. But the problem isn’t the volume, the problem is that mail programs don’t scale. Companies mailing lower volumes can get away with sloppier practices. One because the chances of hitting bad addresses increases with the number of addresses you have. But the other is that filters do take volume into account. It’s not that the volume directly causes the filters to trigger, but volume causes the filters to look harder at mail. If the reputation and metrics are good, the mail is fine and hits the inbox. If they are poor, then mail hits the bulk folder or is filtered.
Overall, volume isn’t a problem, but increasing volume can expose fundamental problems in a mail program that result in delivery issues.