Tech Audit

E-Mail Evils

  • Print.

Good wine and good lawyers get better with age. But one thing that hasn’t gotten better is e-mail. Now that it is everywhere, e-mail is harder to use in a way that makes sense.

Now, we are not advocating getting rid of e-mail, but its ev­­er-increasing limitations must be noted.

Fifteen or 20 years ago, the e-mail system had three big problems:

• Most people didn’t have it.

• Proprietary e-mail that did not run over the Internet still had a strong foothold.

• Much bandwidth was at a pathetic 1200 baud. At that transfer rate, a large file was functionally equivalent to a computer virus, bogging things down.

Then along came real computer viruses attached to e-mail. Some organizations instituted electronic rules that blocked executable files—ready-to-run forms of programs that may be viruses or worms—or even blocked all attachments. And e-mail volume was already becoming a problem when spam suddenly appeared.


If one develops good e-mail management technique, one can probably manually handle about 30 spam messages a day. But it is not unusual for someone with a public e-mail address to receive 200 spam messages a day—an impossible volume without a spam strategy.

The best spam strategy is a spam filter program. But with a spam filter, no matter how good the algorithm, it is impossible to guarantee that some real e-mail won’t get deleted along with the spam.

It is also possible to require white-listing (pre-approval of an e-mail address) for e-mail to get through. Lots of weak­nesses there, not the least of which is not knowing in ad­vance from whom important e-mail may come.

One doctor client told David Hirsch to communicate with him primarily by e-mail. Hirsch got all the doctor’s messages. The problem is, it took awhile to realize that the doctor was getting none of Hirsch’s messages because the doctor had not white-listed Hirsch’s address. Many organizations block bounce messages, so the send­er does not know the message didn’t reach the addressee. And even if the bounce goes out, it may be filtered on the other end.

Manually creating rules routing e-mail at the user level (as opposed to the server level) also creates holes. The No. 1 weakness there is you won’t be able to keep up with the changing situation.

One’s outgoing e-mail may go to the bit bucket because a firewall or a mail server has a relay trap, and for whatever reason, your e-mail may look like it is a relay—a technique used to distribute spam.

Or your domain may have been put on one of the many spam lists that Internet service providers and others subscribe to, blocking its mail as spam. While that is not like­ly, it has happened to legitimate domains, including the ABA. Getting de-listed can be a chore.

Ubiquitous bandwidth and its relative cheapness also tend to foster a lack of concern with e-mail usage both in size and volume. Some may remember becoming skilled at packing maximum information into a brief long-distance telephone call to cut costs. But words are now cheap. Syn­tax and diction, if not irrelevant to some e-mail writers, frequently are of little concern.

And with nearly everyone now using electronic mail, the average e-mail skill level is below what it was 15 years ago, even though there is more to­tal skill out there.

This tends to facilitate mistakes such as misaddressing, long subject fields, overquoting or underquoting prior messages, using e-mail for ill-suited purposes (like attempting to resolve conten­tious issues or venting) and too much cc’ing.

On top of that, e-mail queues can now be so long that even if your message gets through, it may get lost in the flood.

E-mail is too useful to eliminate, so developing e-mail technique is essential. Lawyers, judges and support staff who pride themselves on communication skills will welcome the challenge.

David Beckman and David Hirsch practice in the law firm of Beckman & Hirsch in Burlington, Iowa. Contact Beckman by e-mail at [email protected] or Hirsch at [email protected].

Give us feedback, share a story tip or update, or report an error.