Patent

This month in email: September 2013

Looking back through the month of September there were a couple things talked about on the blog.

Patent trolling, meet RPost

Yesterday I mentioned Ubicomm and their patent trolling based on an ancient Xerox patent they acquired earlier this year. I think the mere fact that Xerox sold the patent says all we need to know about how applicable it is.
The other patent troll in the email space right now is RPost. Steve did a blog post about RPost patent trolling about a year ago.
This summer, RPost’s legal team started calling different companies in the email space. I got a call the first week in July. After introducing himself as their lawyer and reassuring me he was not sending me legal threats, he started to ask all sorts of questions about our technology. I declined to answer any of them.
The lawyer then said he had some paperwork to send me and asked for an email address. I told him we do not accept legal service by email and that he could send me any relevant paperwork to our address of record. If I had any questions about RPost having a real product, it was answered when the lawyer didn’t tell me that RPost technology is all about secure delivery of legal papers.
Others in the email space started reporting similar calls and letters from RPost around the same time.
It’s been 2 months (almost to the day) since RPost’s lawyer called me and we have yet to receive anything from them. Clients of mine, however, have received papers from RPost. The papers instruct recipients to read RPost’s patents and notify RPost if they are infringing.
Yes, RPost are such cheapskates they expect their target companies to do the work identifying any potential infringement. Or possibly it’s just that they have so little money they can’t afford to pay their legal team. Certainly my experience is that telling them to send us postal mail is enough expense? time? to stop them from moving forward.
My recommendations to anyone receiving a letter from RPost (or anyone else claiming patent infringement) are pretty simple.

Patent trolling

I’ve recently become aware of activity from a couple patent trolls in the email space.
One is UbiCommLLC. They appear to be suing the Internet for violating a patent they acquired from Xerox. The lawsuit claim is that shopping cart abandonment emails violate a patent they own.
I did a little reading on this recently. UbiComm LLC formed itself in January of this year and acquired a Xerox patent the following month. They’ve since gone on an infringement spree, suing other printer companies, retailers, ESPs and that’s just what I can find in 2 minutes of searching.
The patent is U.S. Patent No. 5,603,054 titled “Method for Triggering Selected Machine Event When the Triggering Conditions of an Identified User Are Perceived.” I read a little of this patent and best I can tell (and I’m not a lawyer) this has zero to do with email and even less to do with shopping carts. Instead, this appears to be a way to identify where an individual is inside a local network and send a message to the machine closest to that person.
This is what I think the use case for the patent is. Take an office building, or even an office complex, or even an international corporation with hundreds of computers and printers and smart phones. Each one of those is connected to the network and is capable of displaying a message to a particular person. Each person in the building wears some sort of tag that is also hooked up to the network. I want to send a message to Bob, so I send a message to Bob. The local network figures out where Bob is, figures out what machine is closest to him and then presents that message to Bob on that machine.
This is conceptually different than email. The sending network doesn’t have to figure out where Bob is, it just sends the message to Bob’s email account. Bob chooses when and where to download the message. It’s not like shopping cart abandonment messages are targeted to my phone when I’m in the car, my office computer when I’m at work and my home computer when I’m at home.
In my non-legal opinion these are nuisance suits. The lawyers at Ratner Prestai seem to agree with me and give good suggestions on how to plan for such a thing.

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.

Patenting whitelisting, then suing people who use it

Thanks to Ken for pointing this one out.
A number of companies, including Surewest, AT&T, Cisco and Comcast are being sued by a company called BuyerLeverage for violating a pair of patents because they’re using Return Path as part of their mail filtering decisions.
I pulled the docs (1-11-cv-00645-LPS).
The patents all seem to center around a system where there is another layer between sender and recipient. The sender and recipient negotiate a deposit before email is delivered.
The oldest patent was filed in October 2001 (Patent 7,072,943).