In notices provisions in contracts, you say what’s required to give valid notice. Among other things, that involves specifying what one or more methods have to be used. The standard alternatives are giving notice by hand, by some form of mail, by FedEx or some equivalent, or by email.
Recently I’ve considered providing for email as the only means of giving notice, but I don’t feel comfortable with that. This post explains why.
It would have been futile for me to consider on my own the implications of giving notice only by email. On Twitter I issued a cry for help, and two heard the call.
One was Neil Brown (@neil_neilzone), a tech-savvy English lawyer with his own law firm, decoded.legal. The other was Meng Weng Wong, co-founder of Legalese, principal researcher at Singapore Management University’s Centre for Computational Law & Legal Tech, and, in a previous life, protocol designer and co-author of RFC4408, an email standard that is now an essential element of the Internet’s anti-spam immune system. What follows reflects my exchanges with them; you’ll find the exchanges themselves at the end of this post.
Here’s all it takes to provide for notice by email only:
For a notice under this agreement to be valid, it must be in writing and delivered by email. It will be deemed to have been received when sent.
That doesn’t take into account that delivery might fail. Here’s a version that does:
For a notice under this agreement to be valid, it must be in writing and delivered by email. It will be deemed to have been received when sent, even if the sender receives a machine-generated message that delivery has failed. If a party sending an email notice under this agreement receives a machine-generated message that delivery has failed, for that notice to be valid the sender must no later than ten business days after sending the email message deliver a tangible copy of that notice with end-to-end tracking and all fees prepaid.
(The purpose of saying even if is that it gives the sender the benefit of the date they sent the email message, but only if they follow up by delivering the tangible copy. The fallback method is delivery by any organization (postal service or company) that provides tracking. Regular or certified mail? They don’t offer the same combination of speed and tracking.)
One advantage of email-only is that it would make the contract shorter, but the fallback mechanism in the quoted provision immediately above requires a few extra words plus, stated elsewhere, the addresses for delivery of the tangible copy, plus around 50 words saying that the tangible copy will be deemed to have been received if it can’t be delivered for one of various possible reasons.
The other advantage of email-only is that it’s easy: press Send and you’re done, unless you receive a message that delivery has failed. But delivery might indeed fail. If that happens, the sender might not be notified. And a message might go into a junk folder or be lost in a flooded in-box, although that would be less relevant if the email address is used only for accepting contract notices.
The way to address these concerns would be to have the intended recipient acknowledge that they received the email:
For a notice under this agreement to be valid, it must be in writing and delivered by email. It will be deemed to have been received when the party to which the email message is addressed acknowledges by notice in accordance with this section 11 (but without need for acknowledgement of the acknowledgment) having received that email message, with a read receipt or an automatic reply not constituting acknowledgment of an email message for purposes of this section 11.
If the sender of a notice in accordance with section 11(a) receives a machine-generated message that delivery has failed, or if the sender does not receive an acknowledgement in accordance with section 11(a), that notice will nevertheless be deemed to have been received when originally sent by email if no more than ten business days later the sender delivers a tangible copy of that notice with end-to-end tracking and all fees prepaid.
Of course, requiring that an email be acknowledged adds some more words. It also means you can’t just send an email and assume it has been delivered unless you receive a failure notice.
I prefer making it a condition to giving notice by email that the intended recipient acknowledge receipt.
That adds only a modest burden. Yes, the contract would be perhaps half a page longer (compared with email-only) or a few words longer (compared with email-only unless the sender receives a failure notice), but I don’t think that represents a meaningful burden.
Requiring acknowledgment also adds an extra step to the process. But instead of just making the process as frictionless as possible, the primary goal should be furthering the purpose the contract. If you send someone an email notice and they don’t respond promptly, that could be a sign that something is amiss. If you follow up and determine that they had missed your email, following up allowed you to rectify the situation. If you follow up and determine that they’re being uncooperative, you know to give notice by the fallback mechanism, and otherwise you proceed to do whatever is appropriate to address the change in the relationship.
If you could have sent an email notice without the requirement that it be acknowledged, you wouldn’t have had the benefit of that early-warning signal. In this respect, email-only is certainly easy, but it’s a little too easy.
In my everyday communications, I’ve learned not to assume that each email reaches its intended recipient. If I send something important, I ask that the recipient let me know that they received it. I don’t see why I should be satisfied with a lesser standard in contracts, where generally more is at stake.
Now, regarding my exchanges with Neil and Meng …
What Neil Brown Had to Say
Here’s what Neil said to me in an email:
A sender will not always get notice that a delivery has “failed”. And even if they do, the implications might not be clear.
For one thing, if the sender’s mailserver receives an error code from the recipient’s mailserver, it’s up to the sender’s mailserver to notify the sender. The sender themselves is unlikely to see the message from the recipient’s mailserver (as that’s a server-server thing, not a server-client thing, so unless the sender is watching the mail server logs, they won’t see it). Given that whether the sender sees the notice that delivery has failed depends on their configuration choices, should the sender be deemed to have received a notice that delivery has failed if the sender’s mailserver receives it, even it doesn’t pass it on to the sender?
And what is a failed delivery? If an email is received by my mail server, but the mail server treats it as junk mail and moves it into my junk mail folder, so I do not see it in my inbox, has it been “delivered”, even though I might never see it? (If the contract says that email is deemed delivered unless the sender receives a machine-generated notice that delivery has failed, an email delivered into a junk folder would be deemed to have been received.)
And when is an email “sent”? When the user’s mail client (e.g., the software on their iPhone) transmits the message to their mail server, or when their mail server transmits the message to the recipient’s mail server?
I think it’s significant that a savvy operator like Neil Brown isn’t comfortable with email-only:
For what it’s worth, I’ve been experimenting with email-based notices clauses, and I’ve yet to come up with one which doesn’t require a health warning for a less tech-savvy client.
The “best” position I have come up with, for a supplier in a supplier-customer relationship, is an unbalanced one:
Both parties agree that notice has been given:
– in the case of us notifying you, one clear day after the time at which we sent the email; and
– in the case of you notifying us, one clear day after you receive confirmation from us that we received your notification.
(I have, however, still carved out notices relating to litigation, since email just isn’t reliable enough.)
In other words, Neil’s proposal would work for clients willing to require that the other side accept email-only notices, but not for themselves. It is, as he says, unbalanced. And he doesn’t want email-only for notices relating to litigation, but they aren’t the only sensitive kinds of notices. Assuming you’re not dealing with day-to-day communications, it would seem annoying to start distinguishing between levels of sensitivity for purposes of contract notices.
What Meng Weng Wong Had to Say
Here’s what Meng said to me in an email:
Imagine a classroom with a bespectacled kid shouting “Pick me! Pick me! I know the answer!” I’m that kid; the spectacles represent a CS degree, and the answer turns out to be as fundamental to the Internet as Donoghue v Stevenson is to the law of torts. In honor of that little snail in the bottle, let’s turn back the clock to the days of snail mail: when your options were hand delivery, certified/registered mail, courier, and … the facsimile machine. While millennials may scoff at the fax, it does have one major advantage over email: if the receiving machine is out of paper, or not turned on, the sender can’t claim the fax went through. The technical term: the fax machine (and hand delivery) are synchronous protocols; email is asynchronous, as are snail-mail and courier. If your mailman learns that your recipient has vacated the premises, your envelope would, presumably, find its way back to you. Yet notice provisions rarely deal with this eventuality, which is analogous to the email problem at hand. More on this later.
Computer scientists call this the Two Generals’ Problem. Imagine two generals, each leading half an army, need to coordinate an attack on the enemy; but they are separated by a forest inhabited by, say, man-eating spiders. Given an unreliable communication channel, how can the generals agree on a time of attack? General 1 sends a messenger: “I intend to attack Sunday after brunch; would 12:30pm be convenient for you? Please confirm you will attack at the same time, lest I blunder into battle without reinforcement; I will not attack unless you confirm.” General 2 sends back a messenger: “I confirm Sunday 12:30pm; but please confirm that you received my confirmation, for I fear this present messenger may be reduced by arachnid; I will not attack unless I receive your confirmation.” General 1: “Hey, got your text, but I now need to be sure that you got mine; sending your guy back with this message as he presumably knows the route. Or maybe he was just lucky with the spiders? Tip him extra if you get this lol.” And so on, ad infinitum.
Protocol designers study this problem in the context of the CAP theorem (consistency, availability, partition tolerance); I will not say much more about this, except that the Byzantine Generals’ Problem (involving any number of generals, not just two) has been mathematically proven to be a Really Hard Problem; hard enough that good solutions to it can become the basis for the very concept of blockchains like Bitcoin and entire cryptocurrency economies valued at hundreds of billions of dollars. https://bravenewgeek.com/tag/cap-theorem/page/3/ offers a good explanation with diagrams; it references widely-respected solutions to the problem of distributed consensus. The solution offered by Neil Brown, where one party is the “primary” and the other the “secondary” in terms of notice authority, is a simple, but workable, case of asymmetric roles.
One other thing. In the scenarios we’ve talked about, the parties are cooperating. Notice provisions are sometimes analyzed under adversarial conditions: I have heard stories where a party deliberately attempted to evade notice by changing their registered address daily. Anticipating such conditions, a sensible sender should reserve some way to unilaterally send valid notice; what if one of the generals converts to pacifism and in the name of the greater good quietly murders every messenger sent his way? Chaos ensues – Apocalypse Now. In the domain of asynchronous protocols, a fallback to registered or certified mail at least grants historical weight to the presumption of delivery. That presumption of delivery favors the sender – as does an email-only provision that does not require confirmation. Requiring confirmation favors the recipient, because they could start playing games. Ultimately, synchronous media are superior: the two generals simply meet in person. That’s why process servers still convey envelopes by hand. That’s why web pages are served over TCP (a connection-oriented protocol) and not UDP (a connection-less protocol). And that’s why fax machines in law firms are routinely configured to print confirmation pages.
Notice clauses are generally silent on what happens if snail mail bounces. Can the presumption of receipt-after-three-days still hold if the mail is returned to sender? Some notices ask the recipient for a consent or a decision. If the notice doesn’t go through, or the recipient times out, should the contract allow the sender to proceed as though the recipient had responded agreeably? Maybe so. As a protocol designer, it bothers me to think that some uncontactable party could hold up an entire workflow. Neal Stephenson recounts a classic tale (in In the Beginning was the Command Line) about a token ring network that crashed every time someone held down the mouse button on their Mac: because the computer was simply waiting and waiting for the mouse button to be released, it didn’t pass the token, and the entire network ground to a halt.
The opposite of a bounce is a read receipt. Modern protocols like WhatsApp display blue ticks to indicate read receipt. That doesn’t make WhatsApp a better medium for serving notice, though: uncooperative recipients can turn off read receipt in WhatsApp, and that takes us right back to the email situation.
Email (the protocol) and Gmail (the 800-pound gorilla) support read receipts to a limited degree, but it’s off by default, and you may have to hunt hard for a way to turn it on. Email marketers have a whole ’nother bag of tricks to do read receipt, but using those tricks in regular business correspondence is inadvisable: first, it feels stalkerish, and second, do you really want to find yourself explaining to a judge the intricacies of invisible 1×1-pixel PNG images on remote servers?
Don’t get me wrong. I like email. I co-founded the first commercial email service on the Internet. Many contracts I’ve signed recently allow for email notices, and I’ve signed more “consent to electronic communications” letters than I can count. But fallbacks are still important. The protocol I prefer is this: if an email doesn’t bounce, then notice is valid. If the email bounces, then you have to fail over to some form of snail mail – certified, registered, or courier. If the snail mail bounces, or the recipient doesn’t respond within the notice period, then the sender has discharged their duty and gets to proceed as they see fit.
In a subsequent exchange, Meng explained that his reservation with requiring acknowledgment was that he’s not keen on snail mail as the fallback mechanism. Delivering a tangible copy with end-to-end tracking allows you to avoid most of the uncertainty of snail mail, so Meng authorized me to say that in that case, he’s OK with requiring acknowledgment.