Electronic Communication: Some Reflections

The role that email has played in the current kerfuffle in the OCA has prompted me to reflect on a number of aspects of how we (as Church) handle digital information, whether electronic mail, documents, parishioner data, or chats. I’ll confine my thoughts to email for now, with the possibility of an expanded version of this later on.

The first question that comes up with regard to email is: Is it secure? Most individuals are not really aware of how email systems work. The diagram below shows, in simplified (and ugly) form, how a message is handled from sending to delivery. Working from left to right, the user composes a message, clicks “Send,” which causes the mail client to give the message to the mail server (a Mail Transfer Agent in technical terms) which in turn queues it up to be sent. The sender’s mail server contacts the recipient’s mail server and transmits the message. The recipient’s mail server places it in a store (a “mailbox”) until the recipient uses a mail client to retrieve, or delete the message. If the recipient chooses to forward or reply to the message, he becomes the sender and the process starts anew. If you really want to see all the details of how email systems are put together, this article has a good explanation of all the pieces.

Basics of mail transfer. Network connections are shown in blue. The mail store ("mailbox") is shown in green.

The email infrastructure on the web is old, dating to the early 1980s, when computer networks were rare, email was a novelty, and computer security minimal. What security infrastructure there is in modern email systems is generally in the form of “add-ons” to the mail clients, to include encryption and virus/spam checking. Thus, a sender can encrypt the message (but not the recipient and other “envelope” details), hand it off to the server, and let it travel to the recipient’s email server as a sealed box until decrypted by the recipient, with a password or other form of authentication. In reality, the majority of email is unencrypted, and most users don’t know how to use the encryption features in their mail readers, if present. Further, existing Internet protocols (IPv4 for those of you with propeller beanies) have no built-in encryption. Thus, the entire system is built on sending email “in the clear.” Anyone with access to the network connections can easily read your email as it goes by for the majority of systems. The only thing preventing others from reading your email from the mail store on the receiving server is the strength of the password mechanism.

In other words: it’s not terribly secure in most environments. The newest Internet protocols (IPv6, again for your nerdniks) will make encryption standard for all transmissions (securing the wires, effectively), but, despite lots of pressure from a declining pool of available network addresses, is still a ways away from full deployment. Even then, people don’t like entering passwords or using biometric cards or similar devices regularly, so the system remains vulnerable to unauthorized or unexpected access simply by using a computer that is still “logged in” or has a saved password that automates the process of logging in (i.e., without ever prompting the user, who might not be the actual owner of the email store).

Page 1 of 3 | Next page