Recent Posts

RPost – email and patents

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.

AOL bounces and false positives

A number of people have been seeing an increase in AOL bounces over the last few days. Some of these are the new rejection 554/421 CON:B1 message. This is, basically, you’ve topped our thresholds, back off.
The other one is a bit more interesting. The error message a lot of people are seeing is 554/421 RLY:SN. Senders should only be getting this error message when they are sending email from a banned address.

Do you have child subscribers?

Al has a short, but informative, post up on Spam Resource about privacy groups filing complaints with the FTC about companies violating the Children’s Online Privacy Protection Act (COPPA). Companies who are alleged to have violated COPPA include Nickelodeon, McDonalds and General Mills.
The underlying issue appears to be the presence of “send to a friend” links maintained on kid focused websites. The consumer advocates are alleging that kids don’t understand that when they send things to their friends what they’re sending is actually advertising.
I talk a lot about informed consent, but don’t often touch the idea of consent from minors. But this is a good reminder that there are other laws than CAN SPAM involved when dealing with children.

Emails that make you smile

This summer’s non-work project for me has been training for a 5K run with Fleet Feet in Menlo Park. As part of the training programs we get weekly emails from the store on Monday. As I was reading through today’s email, I found myself smiling and happy. Lisa, who is one of the store owners and writes the emails, is just so happy and bouncy and thrilled to share her love of running and that comes through in the newsletter.
Our group’s primary coach is the other store owner. During runs we often talk about random stuff, and when I tell people I do email delivery, they always start talking about their experience with email and spam. One night I was running with Jim, and we were talking about Jim’s experiences with sending email. He mentioned their ESP and talked about how convenient it was. But then he mentioned he wasn’t sure that they were sending enough mail (which made me laugh hard enough I almost tripped on a curb).
I realized I am not just a delivery expert when I started thinking about all the ways they could increase the amount of email they send, while still maintaining the quality and the friendly feel of their bulk emails. What could they offer local runners that would increase the value of the store to them? The first very obvious thing was a race calendar. There are dozens of local races every week, telling folks about upcoming races and entry deadlines would be a way to contact folks regularly without it always being a “buy stuff from us!!”
What commercial emails have you gotten recently that have made you smile?

Mail.app outs lazy marketers

The default mail client on OS X is Mail.app. In recent versions it does it’s best to bundle threads of email together to make it easier for you to keep track of conversations via email – they appear in the list of messages as a single entry with a badge showing the number of messages in that thread. There are standard ways to track mail threads, but they sometimes get broken by mailing list software, so Mail.app also bundles together messages with an identical sender and Subject line.
That has an unexpected side effect, when it comes to email marketing.

That little “4” badge on the right tells me that this is the fourth time Marriott have sent me this same email (over a period of several months) and there’s really no need for me to open it and read it again.

Reporting email disposition

Most regular readers know I think open and click through rates are actually proxy measurements. That is they measure things that correlate with reading and interacting with an email and can be used to estimate how much an email is wanted by the recipients.
The holy grail is, of course, having ISPs report back exact metrics on what a user did with an email. Did the user read it? Did it stay open on their screen a long time? Did the user just mark it read or throw it away? What happened to the message. Marketers would love this information.
It’s unlikely the ISPs will ever provide this information to marketers. Take away all the technical challenges, and there are some significant ones there are still social challenges to making this data available. Current user contracts protect the privacy of the user, local laws prohibit sharing this data. And, there is the vocal group of privacy advocates that will protest and raise a big stink.
I’m not sure why email is gets the special treatment of expecting the channel owners to provide detailed disposition data. In no other direct marketing venue is that information collected or provided. TV stations can’t tell advertisers whether or not someone watched a commercial, fast forwarded through it or got up to grab a beer from the fridge. The post office can’t tell direct mail marketers whether or not a recipient read the mail or just dumped it in the big recycling bin the post office provides for unwanted messages. Billboard owners can’t tell advertisers how many people read the billboard.
Since we can’t get exact read rates from ISPs, what do we do? We look at proxy numbers.
Read rate directly measures who opened the message. Open rate is a proxy. It’s who displayed images in the message.
Read rate can be measured only by people who have access to the user’s inbox. The ISPs can measure read rate because they have full access to the mailbox, but this requires the user to access the mailbox through webmail or IMAP. Some third party mailbox addons can measure it, but this requires the cooperation of the mailbox owner. If the mailbox owner doesn’t install the reporting tool, then the 3rd party doesn’t have access to the data. Only groups with access to the end users mailbox can measure this rate.
Open rate can be measured by people who have access to the server images are hosted. Senders and ESPs and 3rd parties can measure it if they provide unique image IDs or tracking pixels in their emails. Open tracking does require the cooperation of the recipient – they have to have images on. No images on, no open tracking. Ironically, ISPs cannot measure open rate, because they have no access to the image hosting servers.
Click rate can be measured by people who have access to the server that hosts the website. The same people who can measure opens can measure clicks. Some ISPs can measure clicks, Hotmail used to pass every URL through a proxy they hosted and they could count clicks this way. AOL controls the client so they could measure number of clicks on a link. I’ve heard trustworthy folks claim that ISPs are measuring clicks and that they’re not measuring clicks (any of the Barry’s want to comment?).
Without controlling the inbox, though, senders have to rely on proxy measurements to judge the effectiveness of any particular campaign. But at least email marketers have proxies to use for measurement.

Penkava v. Yahoo: wiretapping

According to stipulations filed yesterday Penkava and Yahoo! have agreed to go to private arbitration. This will happen before September 1, 2013. Also filed yesterday was an agreement that Yahoo! has until September 7, 2012 to respond to the complaint.