On Discovery and Email

If you’re involved in any sort of civil legal action in the US Courts – whether that be claims of patent violation, defamation, sexual harassment or anything else – there’s a point in the pre-trial process where the opposing lawyers can request information from you, and also from any third-parties they believe may have useful information. This phase is called Discovery.
US civil discovery has very few limits: you can demand, backed by the power of the court, any material or information that might be reasonably believed to lead to admissible evidence in the case. That’s much, much broader than just relevance, and it allows fairly prolonged fishing expeditions not just for admissible evidence, but also for background information that will allow the opposing legal team to better understand both the case and the people and companies involved in it. Often the discovery phase leads to both sides agreeing on how strong a case it is, and deciding to settle or drop it rather than taking it to trial.
One aspect of discovery is interrogatories and depositions – asking someone a list of questions, and having them reply in writing or in person. While most people will be honest in their replies in that situation, they’re under no obligation to be helpful or cooperative beyond answering, minimally, the questions they are posed. (In a spam case I was involved in as an expert many years ago one of the lawyers was explaining what the oppositions lawyers might ask and told me “If they ask ‘What do you recall was said about <X>?’ you can tell them that I said he was an asshole.”). The information from these can be vital, but it’s a lot of effort to acquire, and unless you already know enough to ask the right questions you might not discover anything useful.
Asking someone to provide documents is another aspect. That might be a literal paper document, or I’d guess more commonly nowadays, electronic data. “Provide copies of any email your employees sent or received that mentioned <plaintiff’s company>.”, “From what IP addresses at what times did this user log in to your system?” …
As someone who does data analysis I love electronic documents. It’s relatively easy to mechanically grovel through thousands of pages of data and crunch it into summaries that you can use to make decisions, or to focus on a useful subset. Give me someones mailbox and I can do the easy stuff, like find any mention of a company, or any link to a companies website. But I can also find the messages they sent while they weren’t in the office. I can do semantic analysis and find the emails that use angry language. I can find all the attachments that were used, open them up and analyze the contents. I can sometimes find where in the world they were when the email was sent – down to which hotel bar, or which office in a building. I can crunch the routing data of their mailbox (and other peoples) and see who they communicated with – and make recommendations as to whether it would be worthwhile to subpoena those people. I can build relationship graphs. And all this applies not just to their work mailbox, but also their private gmail addresses, if it’s a reasonable assumption that any communication there might lead to any relevant evidence – and, well, it’s always a reasonable assumption. (And that’s just email – I can often pull similarly useful data out of web logs and forum posts and so on too).
The discovery process can be long, and can consume a lot of resources (time, legal fees) and work focus from the people targeted by it. Making analysis easier (and hence cheaper) makes it reasonably possible to expand and extend the discovery process to find additional data. Whether that’s good for you or not depends on the details of the case and whether you are the one doing the discovery.
None of this is intended to be legal advice, nor even a description of the process by someone with any legal training – it’s just some aspects I’ve noticed from my limited experience of the process as an expert working with some very good lawyers.
Finally, another piece of advice a lawyer I was working with gave me some years ago was “Always assume that anything you write anywhere may be made available to opposing counsel. And when it comes to legally sensitive matters, use email just for sending copies of documents that will be provided to opposing counsel and for scheduling ‘phone calls where you’ll discuss other details. Nothing else.”.

Related Posts

Canadian Anti-Spam Law

A few years ago, Canada passed an anti-spam law (CASL). In the time since then, the Canadian Radio-Television and Telecommunications Commissions (CRTC) have been working to establish the regulations to implement the law. Those regulations appear to have been published recently. Matt Vernhout, a email expert and Canadian citizen, published a link to the regulations and a summary of the rules.
There still doesn’t seem to be a firm date for when CASL will be enforced law. Matt says he’s hearing that the date will be around October. We’ll see if it slips from that.
 

Read More

SOPA / PIPA

I’ve not mentioned anything about the Stop Online Piracy Act (SOPA) and it’s companion bill the Protect Intellectual Property Act (PIPA) that are currently making their ways through Congress. Both bills put a lot of obligation on the ISPs to stop bad traffic on the Internet. Unfortunately, it seems no one writing the bill asked anyone with technical or operational experience for input. Many of the obligations are going to significantly impact ISP functioning and will probably degrade service for users.
The Messaging Anti-Abuse Working Group sent a letter to congress yesterday (PDF link), outlining the issues with SOPA and PIPA. I found it explained the bills and the flaws much better than many other summaries.

Read More

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.

Read More