So, in Contracts yesterday, there was a fair bit of discussion about “The Mailbox Rule.” The case we our book chose to introduce this was Adams v. Lindsell.
On Sept 2nd, Adams sent a letter to Lindsell offering to sell some wool.
The letter, however, was misrouted and not delivered until Sept 5th, at which point Lindsell promptly returned his acceptance, once again by mail.
On Sept 8th, Adams gave up on Lindsell and then sold the wool to another person.
On Sept 9th, Adams received Lindsell’s acceptance.
Lindsell then sued Adams for breach of the contract that he had been offered and had accepted.
Anyway, the issue here is “When does the offer, acceptance, and possible revocation actually happen, given the delays in communication.”
To skip to the end, the commonlaw rule is that Acceptance is effective when it is sent, but a revocation is effective when it is received. In California, and some other states, the revocation is effective when it is sent, however.
Anyway, our book included a few cases written by judges of the belief that because there are now communications methods faster then mail, that an overtaking communication such as a phone call should be allowed to withdraw offers or revocations after the communication has been dispatched.
This, of course, leads to the fact that you really cannot call the post office and say “Hey, I didn’t want this delivered – please stop.” They simply don’t do that. Also, you cannot steal your letter out of the offeree’s mailbox after it’s been delivered. These would be criminal acts. Expensive ones.
My first thought, of course, was “What if you are using Federal Express?” With a tracking number and authorization, you can call them up, speak to the nice people, and change the destination address, or even cancel a delivery.
The class veered into the realm of Email, and whether one can recall them, which leads to the reason we are here today.
The first email was sent in 1971 and was a test message to the author of the software from himself. I think this article is referring to the first one between computers, however.
Long ago, before everyone had an incredibly powerful computer on their own desk, people shared computers, by connecting to them with dumb terminals. Some of the first messaging systems were simply shared file-folders: one would simply create a document in a folder which other people could read. Of course, this is more of a bulletin board: anyone could post, read and remove anything. So someone would write some software to enforce permissions. The software would allow the insertion of a document into another person’s folder (or spool). The spool would not be readable (or erasable) by anyone but its owner. This is a mailslot in a locked office: anyone can come by and drop something through it, but they cannot take it back once it has been sent.
All of this is fairly simple because we are talking about people sharing one computer, much like two people with their own private offices share a larger office. Things get a little more interesting when there are two or more computers connected in some form of network.
We will start with the “store-and-forward” system. The was traditionally implemented through a protocol called “UUCP” or “Unix-to-Unix Copy Protocol". UUCP provides the ability for a user of one computer to direct that files be marked to be copied to another computer at some point in the future. Periodically, the system finds that files have been so marked, and then connects to the other computer (usually through a modem) and then delivers the files. At this point, the receiving computer would determine the addressee of the message, and then deliver using the mailslot method outlined above. To take the shared office metaphor a little farther, now you can deliver local mail through your neighbor’s mailslot, or address it and put it into the “outgoing” mailslot. Every night, a courier comes by, picks up the outgoing mail, runs it to the destination office, and stuffs it through the correct slot (or hands it to a secretary who handles the slotting).
As store and forward networks became larger, they would come up with various routing methods: instead of delivering the files directly, they would be passed to hubs, or they would merely be thrown “upstream” in hopes that someone will be able to determine the proper direction to pass the files. This is somewhat similar to the post-office: there is a clearinghouse entity that figures out exactly where to move the mail based on the addressing.
Jump forward a few more years, and more and more computers are directly connected to the Internet. UUCP is replaced with “Simple Mail Transport Protocol", which removes some of the store-and-forewardness and is considerably more efficient. It would be a little like replacing the courier or postman with a fax machine: much more oriented towards quick, frequent, and direct connections.
So really this is basically the evolution of copying small files from one computer to another based on addressing and ownership information.
We will now go into more detail as to what happens at the destination.
On some systems, where users each have a private directory, email is simply copied into that directory. Then they can use software to read the mail. This is useful when many people share access to a computer.
In this day and age, however, nearly everyone gets a computer on their desk. While it is possible to deliver people’s messages directly to “their” computers, not all of those computers are continuously on the Internet (dial-up users) or even powered on all the time (laptop users). This means that there is usually a central computer which stores the mail: users collect their mail from the server using their mail reader software. This also lets you put your eggs into one well-guarded basket – you hire some smart guy to run your server, make backups, and support it. If you lose your laptop, you just get another one and pull your mail off the server, which is less likely to be lost. Now, instead of a mailslot in your office, you stop by the the secretary every day and pick up a bundle of letters – and if you don’t come into the office, or if your office floods, you can just have the secretary fax you a copy of your letters.
The simple way to get your mail from the server is POP3 (Post Office Protocol). It really doesn’t let your client do much more then say “Hey, any new mail? Give it to me! Ok, this mail is read, so it isn’t new when I ask again! Bye!” IMAP4 is a little smarter: you can move mail between folders, delete things, even do searches without downloading every email you’ve ever received.
The more complex ways are “Enterprise-level” systems such as Microsoft Exchange, Lotus Notes, and Novel Groupwise. These are engineered for organizations in which most email is sent within the organization as oppoesd to between organizations. They tend to be smarter, and guess what: they resemble our very first method of delivery, with a large database of messages, some software for coordinating who can read what, and a way for people to access the software from their desktops.
Because of this, it is fairly easy to implement things like email-recall. Because sending the message merely uploads it to a known central server who can authenticate the sender, the sender can ask that server to yank it out of the receiver’s mailbox. This is not possible with something like SMTP, where the mail is sent to a machine owned by someone else, who may not trust your request. This is the difference between asking the secretary to open up the neighboring office door and retrieve the mail you slipped through the slot, and calling up the Post Office and asking them to not deliver a letter. The secretary knows who you are, but the Post Office either cannot or will not verify your identity as the sender, so they will not act on your behalf.
At this point, we’ve shown why it is possible for an AOL user to cancel a message sent to another AOL user, or a person within a University to cancel a message to a person within that University: the message never leaves the authority of a single central entity that can verify that it has not been modified, and that the sender is indeed the one asking to cancel the message. If someone sends from the University to AOL, however, AOL will generally not be able to verify the sender’s identity.
Anyway, I failed to speak up in class because it would take a 10 minute lecture with a dry-erase board. I decided to write things down and have spent 40 minutes rambling about email protocols. Join us in the next episode when we explain how to implement email repudiation across untrusted system via cryptographic authentication!