The case of the day is Elsevier, Inc. v. Chew (S.D.N.Y. 2018). Elsevier, a publisher, sued twenty unknown defendants, alleging they were infringing its copyright by selling counterfeit textbooks on eBay. By way of subpoenas to eBay and PayPal, Elsevier was able to obtain the names and email addresses of the defendants, though not their physical addresses. Some of the defendants operated in Malaysia, some in China. Elsevier moved for leave to serve process by email under FRCP 4(f)(3). They proposed using Re@dNotify, a service that purports to be able to prove when an email recipient has read an email.

The court granted the motion. Easy case: Malaysia is not a party to the Hague Service Convention, and though China is a party, the Convention did not apply, because the defendants’ addresses were unknown. (The court’s discussion could have been clearer; it suggested that the uncertainty about the physical addresses was a reason not to require first resort to the Convention rather than a reason why the Convention was simply irrelevant).

So the case was not that interesting from a doctrinal perspective. But I do want to discuss the use of services meant to prove that an email was read by the intended recipient. Back in 2012 I mentioned a company, RPost, that sells such technology. I don’t know the details of RPost’s technology or Re@dyNotify’s, so I am just going to discuss the issue in general terms.

We send and receive email using a standard known as SMTP: the Simple Mail Transfer Protocol. SMTP itself does not provide for what we ordinarily think of as “read receipts.” An SMTP server will send a “reply code” to the client, from which the client knows that the server (if it is working properly) accepts responsibility for delivering the message, will retry delivery a reasonable number of times if delivery fails due to a transient condition, and will send the client a notification if delivery fails at the end of the day. But in practice you can’t infer from receipt of a positive reply code that the email actually made it to the recipient’s inbox, let alone that the recipient read it.

There are extensions to the SMTP standard that allow for “message disposition notifications,” or MDNs. The client can request an MDN by putting an appropriate header in the email message it transmits. But the MDN is a mere request: the standards do not require the recipient’s “user agent” (the software the recipient uses to receive and read emails) to respond to the MDN.

So in conclusion, SMTP and its extensions do provide a means for an email recipient to notify the sender that he or she has received or read an email message, but only at the recipient’s option. That’s obviously not good enough for cases of defendants who mean to duck service.

So what can an email sender do? Again, I have no idea about RPost or Re@dyNotify in particular. In general, though, email tracking services take advantage of the fact that modern email is often not just plain text, but includes content in HTML: the Hypertext Markup Language in which almost every page you read on the web, including this one, is written. An email whose contents are in HTML can include, for example, images retrieved from the Web. So, for example, if I include the following line in an HTML email message to you,

You will see the following image in your email:

What a typical email tracker does is insert a link like this to an invisible, 1×1 pixel image that you don’t see and that is hosted at a URL that the web tracker creates specifically to track the email in question. When you view the email, your computer sends a request, via the HTTP protocol (just like your web browser) to the HTTP server where the image is hosted, and that server records the request in its logs. Presto! Evidence that you opened the email, which will include the date, the time, your IP address, etc.

Now, there may be more advanced versions of this, but the version I’ve described, which I believe is the most common, is trivial to defeat: you can configure your email program not to display images unless you expressly tell it to. A security-conscious email recipient might also review the raw HTML in an email message before opening it using his or her email software.

But aside from technological limitations—can you be confident you will know that the email was read?—this technique, called a “web bug” raises some legal issues. The two bar associations that have addressed it, New York and more recently Alaska, have pointed out the potential ethical problems for lawyers using web bugs in their email communications, though the scope of both opinions is limited and the prevalence of web bugs in everyday commercial email may have overtaken the New York opinion particularly, since it dates from 2001. It’s possible there are other potential issues, too, though I have not researched it.

The bottom line seems to be that if an email recipient is willing to tell you that he or she has read your email, then there’s no need for a technical solution, but if the recipient is unwilling to tell you, and he or she is technically sophisticated, then there probably is no technical solution.