United States mail, known as snail mail in electronic circles, is private. Among the federal crimes that you don't want to be found guilty of are opening other people's mail and tampering with their mailboxes. It's even more serious if a mail carrier reads someone's mail or interferes with its delivery. The US Postal Service doesn't advertise these facts much, but most people sense that the love letter sent in the mail is guaranteed to be private, at least until your paramour leaves it lying around after reading it. This sense contributes to the impression that electronic mail systems are equally as private, whereas in fact, no laws require them to be private, on the one hand, and on the other, email is easy for system administrators to surreptitiously read if they wish.
This misconception of privacy has surfaced twice in the ugly battlefield of jurisprudence. The first case, brought by ex-Epson email administrator Alana Shoars, accused Epson management of ordering middle management to systematically read private email messages. Epson denies everything, but refuses to guarantee privacy. Shoars was not so much upset by the concept of non-private email, but by the secretive and harmful way in which Epson used the resulting knowledge. A California judge dismissed part of that case, saying that electronic mail does not fall under a California law protecting against telephone and telegraph wiretapping. Though the federal Electronic Communications Privacy Act (ECPA) of 1986 protects electronic communications, the ECPA only covers outside intervention. In other words, what you do in your own house or company is your business. Sleazy, perhaps, but your business.
The second surfacing of the privacy issue developed as a case against Nissan Motors, brought by two information systems specialists, Rhonda Hall and Bonita Bourke. Their manager reprimanded them for using company software for personal use. He used copies of electronic mail messages as supporting evidence. Again, the crux of the issue seemed not to be the non-private nature of the mail, but the deception foisted on the two that the mail wasn't monitored. Noel Shipman, Alana Shoars' attorney, is handling this case as well. Mr. Shipman has no prior experience in electronic privacy issues, but I suspect he'll be pretty good at it before the issue disappears.
I haven't made up my mind about this issue. On the one hand, I detest snoops and electronic peeping Toms. On the other hand, I don't think the government should regulate internal company policies. Our government has much to do that's more important and shouldn't meddle in private affairs past basic protection (and no, I'm not sure if electronic privacy at the company level qualifies as a "basic" protection). I can think of a relatively simple method that would eliminate the entire issue, though. What if every electronic mail system, and I do mean every, encrypted each mailfile, using the username as the encryption key? The only way to read the mail would be from the account to which the mail was sent, because no other account could decrypt the message, no matter what privileges the account had. If the encryption was built into the base system, it would make no difference to users, who would never notice, and if it was implemented well, it wouldn't drag down the system too much.
Lest I sound too clever, let me add that something approaching this system exists in an email package called cc:Mail. cc:Mail runs on Macs and PCs (and just added the ability to administrate the system from Macs, to its credit) and performs this automatic encryption on all messages. The network administrator can change users' passwords, but cannot read their mail or perform any other sort of electronic snoopery.
In light of this, I have several suggestions for anyone potentially affected by these issues. First, make sure your organization guarantees either that mail will or will not be private and publicizes the decision. That will solve many problems. Second, suggest repeatedly to the makers of your email package (if it's not cc:Mail) that they implement automatic encryption as soon as is feasible. Third, if you see no sign of compliance from your email supplier or plan to set up a new system, consider using cc:Mail. Note that I know little about cc:Mail other than what the reviews have said - use the command --find whole "cc:Mail"-- (in the message box in HyperCard and don't include the dashes, of course) to search your TidBITS Archive to find the three relatively recent reviews of cc:Mail.
Universal automatic encryption would remove almost all problems related to private email and would satisfy everyone except those who steal useful information from others' mailfiles. Another advantage would be the removal of responsibility from the network administrator. To use an example from a networking conference at which I spoke last summer, what if a network administrator "happens" to see a mailfile organizing the takeover of a campus building by a radical group? Common sense and duty require that person to report the incident to the authorities, but if the university guarantees private email without encrypting mail, the administrator could be guilty of breaking university policy. So the administrator sits between the proverbial rock and a hard place. It could become more complicated yet, if the takeover could have been prevented (by breaking campus policy) and someone is accidently hurt or killed in the process. It's all too complicated to decide hypothetically, but would be completely moot if that email was encrypted. Ideally, such encryption would force policy makers to admit that they have no say over mail which may contain undesirable content (sex, drugs, and rock 'n roll) and merely passes through their sites on its way elsewhere.
Technology needn't make life more difficult, particularly in this case, where it can remove such issues from everyday life and from the legal battlefield. Lawyers simply don't need our business and it would be great if we didn't need them.
Current Events (CE newsletter) -- Winter-90, pg. 3
InfoWorld -- 21-Jan-91, Vol. 13, #3, pg. 33
InfoWorld -- 21-Jan-91, Vol. 13, #3, pg. 85
InfoWorld -- 14-Jan-91, Vol. 13, #2, pg. 5
InfoWorld -- 22-Oct-90, Vol. 12, #43, pg. 58