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.

Two hours later I receive the promised “RegisteredReceipt™”. It contains some information about the email, and a trace of the SMTP transaction – excluding the DATA – which is nice. I’d turned on ESMTP Delivery Status Notification functionality, which allows a sender to request the recipient MTA send an email to confirm delivery or rejection, to see what would happen. My MTA sent that DSN email to rpost, and they included it in as part of the RegisteredReceipt mail. They didn’t HTML escape it, though, which means anything surrounded by angle brackets – such as email addresses or message ids – is treated as an invalid HTML tag and not rendered to the user. It also means that as a recipient I could inject arbitrary HTML into the mail that RPost are sending to their users, which opens up a lot of interesting attack vectors.
This is not a service I would purchase.
Why were we looking at this again? Right, patent trolling. I’ll take a look at their patent claims later in the week.