Recent Posts

Equivocating about spamtraps

What is a spamtrap? According to a post I saw on Twitter:

I linked to Al’s post about misdirected emails and how annoying it is for people who receive emails. I’ve previously talked about the problems associated with not handling misdirected emails properly.
It’s really annoying getting email that you never signed up for. For instance, one of my email addresses gets quite a bit of misdirected email. Oddly enough, much of this mail comes addressed to “Mrs. Christine Stelfox” and advertises various services. The problem is, I’m not Mrs. Christine Stelfox and I don’t live in the UK.
I’ve been getting this misdirected email for a while. In fact, I’ve even tried to track down the source of this just to make it stop. But I can’t seem to get that to happen. The senders tell me simply that I opted in, and that if I want to opt-out, here’s a link. Sometimes I have more luck contacting ESPs, but not always.
In fact, recently I reported spam to Mrs. Stelfox to a European based ESP. I got a response from their delivery head, who asked a lot of questions about the email address. What kind of spamtrap was it? How long had I had it? Is it possible it’s a recycled address? It’s really not, though. It’s an address I’ve had since early 1994, and it’s not really a trap as I still actually use if for some me. But I’ve not used it for commercial email since sometime in the late ’90s. And I’ve certainly never claimed to be a Mrs. Stelfox.
This really isn’t a case where I forgot I signed up. This isn’t a case where someone had the address before me. This is either some confused person using my address or some company in the UK selling my email address as belonging to someone else. I’ve tried to track this down in the past to get off the list of whomever is selling this address. But I’ve never had any luck.
There isn’t a lot of recourse here. I can continue to unsubscribe the addresses, but that doesn’t resolve the underlying problem. The underlying problem is that many marketers think it’s acceptable to purchase (or append) email addresses with no regard for the fact that sometimes their data suppliers are wrong.
It’s not just this one address, either. Another one of my email addresses is being sold as “Mrs. Laura Corbishley” of the UK as well. Sometimes I get the same spam to Mrs. Christine Stelfox and Mrs. Laura Corbishley. Other times I get different spams to each address, possibly because Mrs. Stelfox is behind some commercial email filters and Mrs. Corbishley isn’t.
Misdirected emails are annoying. They’re a problem for the people who keep getting them and can’t make them stop. It’s really important that ESPs, companies that send email and companies that sell email addresses have some way to make that mail stop. It doesn’t matter that half a dozen ESPs have put Mrs. Stelfox in their suppression list. Senders are still purchasing that data and are wasting their money. I am still getting spam.

Misdirected email

Al has another post about another company sending mail to a customer that gave an email address that didn’t belong to them. The person receiving the misdirected email has no effective way to make it stop, and is getting more and more frustrated with the ongoing spam. (Consumerist article)

Creative HTML Table Abuse

There’s an old-school ’90s HTML design trick that dates back to the dim and distant past before we had decent layout control in CSS. That’s “slicing” – chopping a large image up into multiple parts, then reassembling them in an HTML table.
If you slice your images in an email and the end user hasn’t loaded images what will they see? They’ll see a rectangular box – either empty or with the image alt text in it. And, if you set the background colour for the table cell, they’ll see that – but only when images are turned off.
If you’re sneaky, you can do clever things with that.
Images off:

The same mail with images on:

Or like this, with images off:

And the same mail with images on:

(There’s more discussion in this reddit thread about it).

You can't technical yourself out of delivery problems

In many cases these days, many more cases than a lot of senders want to admit, delivery problems at the big ISPs are a result of sending mail recipients just don’t care about. The reason your mail is going to bulk? It’s not because you have minor problems in your headers. It’s not because you have some formatting issues. The reason is because your recipients just don’t care if the ISP delivers your mail or not.
A few years ago the bulk of my clients hired me to do technical audits for their mail. I fixed a lot of delivery problems that way. They’d send me their email and I’d run it through tools here and identify things they were doing that were likely to be causing problems. I’d give them some suggestions of things to change. Believe it or not, minor tweaks to headers and configuration actually did make a lot of difference in delivery.
Over time, though those tweaks less effective to fix delivery problems. Some of it is due to the MTA vendors, they’re a lot better at sending technically correct mail than they were before. There are also a lot more people giving good advice on the underlying structure and format of emails so senders can send technically clean email. I started seeing technically perfect emails from clients who were seeing major delivery problems.
There are a number of reasons that technical fixes don’t work like they used to. The short version, though, is that ISPs have dealt with much of the really blatant spam and they can focus more time and energy on the “grey mail”.
This makes my job a little harder. I can no longer just look at an email, maybe run it through some of our tools and provide a few suggestions that fix delivery problems. Delivery isn’t that simple any longer. Filters are really more focused on how the recipients react to mail. That means I need to know a lot more about a clients email program before I can even start to identify what might be causing the delivery issues.
I wish it were still so simple I could give minor technical tweaks that would appear to magically improve a client’s delivery. It was a lot simpler process then. But filters have evolved, and senders must evolve, too.

5 Years

It’s been 5 years since my first post here at Word to the Wise. 5 years and over 1150 posts.
In that time I’ve written about a lot of topics relevant to email delivery.
I’ve talked about permission and why it’s a relevant part of email delivery. I’ve discussed spamfilters and why understanding how they work improves the decisions senders make about email delivery. I’ve talked about blocklists and filters and how they are a part of the email landscape senders have to navigate. I’ve talked about reputation and engagement relevance.
I’ve also talked about the things that show up in my own mailbox. Like some of the spam I receive. I’ve even used that to point out what spammers do.
Steve‘s written quite a bit here, too. Often his articles are much more technical, like how he tracks down spammers.
We’ve written about legal cases, including e360 v. Spamhaus, which was the subject of my inaugural post. I also followed the case of Holomaxx v. Hotmail and Yahoo. And, of course, how different countries create and enforce anti-spam laws.
I have no idea how many words I’ve written in the last 5 years, but Steve swears to me it’s enough to write a book about email delivery. However many words I’ve typed into the ether, it really is the folks who participate here in conversation, who email me directly with questions and comments, who stop me at conferences and tell me how much they like reading the blog that keep me writing. I’ve enjoyed blogging way more than I thought I would, but I wouldn’t enjoy it half as much if readers didn’t enjoy it, too.
Thanks so much for reading here over the past 5 years. It’s been a lot of fun.

Who are Rpost?

Rpost are an email service provider of sorts. You may not have heard of them, as they focus on a fairly niche market – electronic contract and document delivery. Their main services are “Registered Email” – which provides the sender of the message with proof that the recipient has read the message, and proof of the content of the message, and “Electronic Signatures” – which allows users to send documents signed cryptographically, or with a real signature scrawled with a mouse. This is all the sort of thing that would be mildly useful for exchanging contracts via email rather than by fax. Laura and I talked with them some years ago, and decided it was a reasonably useful service, but one that would be difficult to monetize.
They’ve recently started claiming infringement on their patents, so I thought I’d take a look at their actual product to see what it had evolved into.
Their current website has some very visible bugs in it’s HTML, and while it mostly looks pretty, the workflow isn’t terribly compelling. I signed up for a free account and sent myself an email. I saw the word “patented” and lists of trademarks prominently on many of the pages.
There’s no obvious way to see messages I’ve sent through their web interface, nor is there any inbox or way to see delivery status from the web interface. Rather you’re sent email to your real email account about each message. Rpost were originally focusing on MUA plugins, and that seems to still be their main approach, with the web interface more of an afterthought. They list 22 MUA plugins, in their Apps marketplace. They don’t have one for Mail.app (the MUA shipped with OS X) nor for any other Mac mail client. They do list a client for iPhone, but clicking on it shows that it’s not been released yet. Web interface it is, then.
I’d assumed that the proof of reading would be handled in the same way other “secure” messaging services tend to work – the email sent contains a link to a web page, and opening that link (optionally after entering a password) to see the real message is the “proof” that the mail was read. It turns out that’s not the case. The full message is in the email that’s sent. The “proof” that it was read is our old friend the single pixel tracking gif. It’s standard open-tracking, nothing more, with all the accuracy and reliability issues that implies. I also get mail telling me about the delivery (subject, recipient, timestamp, message-id) and a promise that I’ll get a “RegisteredReceipt™” in two hours.
On the technical side of things, RPost are using SPF correctly. They are not using DKIM to authenticate the message, nor any sort of in-band cryptography such as S/MIME or PGP. They’re including Return-Receipt-To, Disposition-Notification-To and X-Confirm-Reading-To headers, in the hope that the recipients MUA will send a notification to one of them. Most MUAs don’t – it’s considered a privacy / security violation, generally. I wonder if the RPost MUA plugins make your MUA respond to one of those?
Using opaque cookies in the Return-Receipt-To: etc. email addresses makes sense, as you can then use receipt of mail to one of those addresses as “proof” that the recipient opened the email. Unfortunately, the email addresses RPost use in those fields are trivially derived from the Message-ID – you take the local part of the Message-ID and add “read@rpost.net” on the end. And RPost include the Message-ID of the message in the notification they send to the sender. So it would be very easy for an unscrupulous sender to send a fake notification that would make it appear the recipient had opened an email when they hadn’t.
There are several email specification violations in the mail sent – the Resent-Message-ID is truncated, and syntactically invalid, the Resent-Date field is syntactically invalid, the email addresses used in the Return-Receipt-To, Disposition-Notification-To and X-Confirm-Reading-To fields are a little broken – in a way that I’m pretty sure leaves them syntactically invalid. The body of the message is HTML, and it violates basic HTML specifications – it has invalid comments, and it nests entire HTML documents inside paragraphs – “… <p><html><head><meta content type></head><body> … stuff …</body></html></p> …”.
One of the important things to do when sending email that you want to be delivered is to try and look like legitimate email, and not like spam. As well as the syntax issues, the mail uses unusual capitalization of several headers (“to:” is valid, but you’ll always see “To:” in legitimate email) and it sends the message as HTML only, not as multipart mime with a plain text alternative. All those things give the mail sent via RPost a spamassassin score of 4.4, with a squeaky clean subject and body. It wouldn’t take much in the message provided by the user to push that the extra 0.6 to reach a SpamAssassin score of 5.0 and end up in the junk folder.

Spamhaus dDOS

I got mail late last night from one of the Spamhaus peeps telling me that they were under a distributed Denial of Service (dDOS) attack. This is affecting email. Incoming email is delayed and they’re having difficulty sending outgoing email. This is affecting their responses to delisting queries.
They are working on mitigation and hopefully will be fully up and running soon.
Updates when I get them.
Update (8/29/2012): mail to Spamhaus should be back.

Broken record…

The Return Path In the Know blog listed 4 reasons mailing those old addresses is a bad idea.
Ashley, the author, is completely right and I endorse everything she said. (Although I’d really like to hear what happened to the customer that added back all those addresses. What was the effect on that campaign and future email marketing?) As I was reading the article though, I realized how many times this has been said and how depressing it is that we have to say it again. And again. And again.
A number of folks have told me that the reason they don’t pay any attention to delivery professionals is because we don’t provide enough real data. They can show that sending mail to old addresses costs them nothing, and makes them real money.
That’s not really true, though. We do provide data, they just don’t like it so they don’t listen to it. Return Path publishes lots of numbers showing that mailing unengaged recipients lowers overall delivery. I can provide case studies and data but companies that are committed to sending as much mail as possible throw up many reasons why our data isn’t good or valid.
The biggest argument is that they want hard numbers. I do understand this. Numbers are great. Direct and clear answers are wonderful. But delivery is a squishy science. There are a lot of inputs and a lot of modifiers and sometimes we can’t get exactly one answer. The data is noisy, and difficult to replicate. One of the reasons is that filtering is a moving target. Filters are not, and cannot be, fixed. They are adaptive and are changing even between one hour and the next.
Delivery experts are about risk management. They are the parents requiring everyone in the car wear seat belts, even though the driver has never had an accident. They are the fire department enforcing fire codes, even though it’s the rainy season.
Risk management isn’t about the idea that bad things will absolutely happen but rather that it is more likely that a bad thing will happen in some cases.
In this case, it’s more likely that delivery problems will happen when mailing old addresses. And if those addresses aren’t actively contributing to revenue, it’s hard to argue that their presence on a list is more beneficial than their absence.
But I repeat myself. Again.

Metrics, metrics, metrics

I’ve been sitting on this one for about a week, after the folks over at IBM/Pivotal Veracity called me to tell me about this. But now their post is out, so I can share.
There are ISPs providing real metrics to senders: QQ and Mail.ru. Check out Laura Villevieille’s blog post for the full details.