Email management definition and solutions

Your e-mail administrators want you to understand the basics. You don’t have to be a guru, they insist; they’d be happy if you’re simply somewhere past “ignorant.” If your eyes don’t glaze over, the admins believe, they could better explain a thorny problem, and the company could make better decisions. You don’t have to solve their problem; but it would help for you to understand it.

So this article won’t teach you to be an e-mail expert in five easy steps. Instead, it helps you calibrate your expectations, identifies the key issues in e-mail management and teaches you the least you need to know.

Nor does this article pretend to explain the vast inner workings of e-mail technology. That’s a big subject, encompassing everything from the choice of e-mail desktop client to server configuration. That pool gets very deep, very fast, so for clarity we separate the subject into e-mail management (people and process) and e-mail technology (servers and the Internet).

Here, we discuss user and IT expectations for e-mail; touch on corporate policies on its use; and explain the relevance of Internet standards. Technology is mentioned in passing (it’s impossible to ignore) but the methods by which all the gears engage is a subject left to another time. (That’s a nice way of saying it isn’t written yet.) Also, this article gives little attention to fighting spam; that topic is covered in Five Things CIOs Should Know about Fighting Spam. Although the subject is relevant, we barely mention e-mail legal issues; that’s a topic for another time (which is a nice way of saying, “Don’t you think this article is long enough?”).

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?
• What are the major misconceptions about e-mail (incoming)?
• What criteria should I use in choosing an e-mail server (and the people to manage it)?
• Sure, sure, we care about Internet standards. Don’t we?
• What guidelines should the company use for setting e-mail policies?

What are the major misconceptions about e-mail (outgoing)?

While everyone depends on e-mail to get business done, it’s not a reliable delivery mechanism. Nothing in the e-mail specifications guarantees that a message will be delivered in a timely manner, or that it will be delivered at all.

The specifications for Internet protocols are called RFCs, which stands for Request for Comment. It’s a terrible abbreviation because it implies that the process is incomplete, but RFCs are indeed the agreed-upon standards from the Internet Engineering Task Force (IETF).

Mail moves around the Internet almost entirely via the Simple Mail Transport Protocol (SMTP). SMTP is not natively secure, it is not guaranteed, it is not trackable and it is not certified. SMTP was engineered to be a best effort-no more than that.

RELATED LINKS

Five Things CIOs Should Know about Fighting Spam

The Case for Outsourcing E-Mail Management

I’m violating our corporate email policy…and I love it!

10 Things You Should Never Put in E-Mail, and Other Communication Tips

Tips for E-Mail Management

NEWSLETTERS

How To

Outsourcing & Staffing

Enterprise  

Relying on e-mail delivery is a bad idea. When e-mail fails, it’s common to accuse the network and e-mail admins of wrongdoing, as though they intentionally threw their bodies between your vital message and its recipient just to disrupt your life. E-mail specifications don’t and can’t require a message to appear in your inbox in the three nanoseconds you desire. This isn’t a specification failure but an acknowledgement of the challenges facing every message in the outgoing queue. Cut fibers, dead mail servers, routing loops, graylisting, DNS typos, filter delays, blacklists-all sorts of things can delay or kill mail in transit. An e-mail message arriving three days after it was sent is perfectly in line with the specifications.

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?
• What are the major misconceptions about e-mail (incoming)?
• What criteria should I use in choosing an e-mail server (and the people to manage it)?
• Sure, sure, we care about Internet standards. Don’t we?
• What guidelines should the company use for setting e-mail policies?

Within an organization, you can make e-mail highly available, reliable and auditable-if you are willing to invest enough human and technical resources toward that goal. However, no amount of effort and expense can make external e-mail function like your corporate mail. Part of that is intentional. Some features of corporate mail systems (such as out of office notices, read receipts, address lookup and verification) carry security concerns. Getting Internet e-mail to work nearly like corporate e-mail can only be done on a piecemeal basis by making special arrangements with outside partners in the specific cases where you need corporate-level e-mail functionality.

All attempts to add reliability to SMTP after the fact (such as adding return receipt) have either failed or been withdrawn from use after massive abuse, primarily by spammers.

Just remember: E-mail isn’t guaranteed. This issue causes your e-mail administrators no end of angst. One wrote, “Boy, do I struggle getting that one through to my marketing guy, who not only expects all e-mails to definitely get to the recipient but also expects me to be able to track whether they got it, how long they read it for, etc. When I first informed him-rather forcefully-that there is no guarantee of delivery, and hence he should not have any contractual or legal obligations dependent on e-mail delivery, he thought I was just being needlessly obstructionist, possibly incompetent.”

A few more short points:

• Read mail server messages before you complain. Many end users act as though e-mail were magically delivered from their computer to the recipient’s computer. In reality, each message transits a number of servers along the way. If faced with a temporary failure to deliver your message to the next-in-line server, e-mail servers retry the connection. (They are supposed to retry in a short period of time, such as 15 or 30 minutes, but a surprising number of servers wait for as long as 12 hours.) If the retry is unsuccessful after a while (say, four hours), the mail server may send the e-mail author a status update. Eventually, the server gives up and sends a bounce message. Your users should be taught to tell the difference between the words “permanent” and “temporary” before they freak out in the direction of the e-mail administrator.
• If the message doesn’t reach the intended recipient, it isn’t always the fault of the technology. Sending e-mail is like dialing a phone number: if the address isn’t right, your mail won’t go where you want it to.
• E-mail is never really private. If you want the message contents truly to be secret, encrypt the file first, and then send it as an attachment. A mail admin may rummage through the mail queue while trying to find the cause of a server problem. If it’s in plain text, it can’t be secret.

What are the major misconceptions about e-mail (incoming)?

End users make many false assumptions about the messages that land in their inboxes.

Often, users are confused about why they received a message when their names aren’t in the To: header. There are many possible answers, benign and otherwise. For example, someone could have placed the user on a Bcc list. In reality, the addresses in the To: and Cc: headers do not necessarily bear any relation to the actual list of recipient addresses. It is only by convention that mail clients place the actual recipient addresses in those headers.

It’s the less harmless messages that cause the problems.

From the server’s point of view, the only thing that matters for routing is the e-mail envelope. This is easily visualized. Grab a sheet of paper, write any name on it (say, “Esther”) and fold the page into an “envelope.” Write a different name on the envelope (for example, “Sandy”). The envelope will be “routed” through the post office to Sandy, independent of whatever the envelope contains.

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?
• What are the major misconceptions about e-mail (incoming)?
• What criteria should I use in choosing an e-mail server (and the people to manage it)?
• Sure, sure, we care about Internet standards. Don’t we?
• What guidelines should the company use for setting e-mail policies?

Spammers and other bulk e-mailers quite commonly put other stuff in the To:or Cc: header, often as part of a long list of actual recipients. This is why the address given in the To: or Cc: header may be alphabetically quite close to that of the person who received the message. It is just the first address in an alphabetically sorted batch of spam recipient addresses. The From: header can be similarly forged, and it may bear no relation to the address that the mail system understands to be the sender of a message (the “MAIL FROM” parameter), which itself may be forged. To confuse the true message source from the naive recipient, a spammer may put one address in the From: header and another address in the MAIL FROM parameter. Either could be set to the address of the recipient, and neither has anything to do with the spammer. Ordinarily, spammers use addresses of innocent bystanders.

Another common user concern is receiving nondelivery notifications for messages they did not send. Here, too, the end user is the unwitting victim. This activity is almost certainly the result of an infected computer. Many viruses and other malware generate e-mail (often spam). As one measure to disguise its origin, the Bad Guys forge the (apparent) return address, using the e-mail ID of an innocent third party. When the message fails to deliver, a “bounce” error message may be generated, which is sent back to the apparent sender (the forged e-mail address).

Unfortunately, neither the user nor the e-mail administrator can do anything to prevent an address forgery. It is inherently impossible, due to the way the mail transfer protocol standards are designed, and it is rarely possible to identify the culprit computer or its operator. The full Internet headers and content of the failure message may provide clues, but they depend on the mail system generating the errors.

What criteria should I use in choosing an e-mail server (and the people to manage it)?

Getting your money’s worth out of an e-mail system requires a carefully balanced investment in technical and human resources and, for many organizations, in outsourcing some elements. There is no off-the-shelf, one-size-fits-all solution.

Your IT shop may feel more comfortable using proprietary software for mission-critical applications. (And for most companies, e-mail is mission-critical; imagine what would happen if it quit working for 48 hours.) However, e-mail is among the server applications that have fully embraced open source. This applies to both the store-and-forward e-mail application itself as well as related software, such as e-mail discussion lists, spam-fighting processors and antivirus tools. If your e-mail administrator wants to use an open-source mail server, listen; a high percentage of professional-quality mail systems are built on Unix- or Linux-based operating systems and use open-source software. Some administrators think very poorly of the proprietary options (though opinions do, of course, vary considerably).

For the most part, however, the key decision is not in choosing the software for your mail server, but in choosing the person to run it. All too often, particularly in small and medium-size companies, e-mail administration is not considered a full-time job. Instead, it’s given as an extra responsibility to someone “technical” (such as an application programmer, or even a receptionist who figured out how to make Excel work). However, keeping up with mail server topics requires far more attention and much more training than many companies assume. This is a major shift from 20 years ago, when e-mail administration was relatively simple-and we didn’t have to worry about spam, viruses, and (a growing problem) lame efforts to protect the enterprise from those threats.

Just as a lazy postal worker can play havoc with paper mail, a stressed-out mail admin can really mess up electronic mail. So many things have to work for mail to work-DNS, network routing, open ports on the receiving mail server-that it’s sometimes amazing that e-mail works as well as it does. So choose the person wisely. (If that isn’t feasible, consider outsourcing your e-mail management.)

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?
• What are the major misconceptions about e-mail (incoming)?
• What criteria should I use in choosing an e-mail server (and the people to manage it)?
• Sure, sure, we care about Internet standards. Don’t we?
• What guidelines should the company use for setting e-mail policies?

At a minimum, your e-mail admin should read and understand at least RFC 2821 (Simple Mail Transfer Protocol) and RFC 2822 (Internet Message Format) and subscribe to a discussion list like SPAM-L.

One mail admin suggested a one-question certification test you can use to find out if the person running your mail system has a clue. Ask the present or prospective e-mail admin, “What mailbox address is required by RFC 821?” If they ask, “What’s RFC 821?” then they should be relieved of mail-related duties on the spot. The correct answer is “postmaster.” Added the helpful e-mail admin, “If they point out that RFC 821 has been supplanted by RFC 2821, they have way more clue than most. And if they also tell you that they’ve taken pains to make sure that ‘postmaster’ doesn’t use spam or virus-filtering because they wish to avoid a listing at rfc-ignorant.org, I’d like to see a copy of their résumé.”

Sure, sure, we care about Internet standards. Don’t we?

The e-mail administration community wants to get the system under control. Spam loads have placed an unnecessary and expensive burden on even the smallest Internet service provider (ISP), and ISPs are motivated to fix whatever they can.

Every technical decision in regard to e-mail has business consequences. This means that you must get the technology right-so the company’s e-mail policies and systems must comply with Internet standards. If you don’t get the DNS record right, or you mess up the Sender Policy Framework (SPF) record, or you implement a dumb method for spam prevention that keeps real messages from getting to your CEO, you will discover a whole new world of hurt. The messages your company sends will be refused by other e-mail servers; customers will go elsewhere when their e-mail is refused (or worse, when it lands in a spam bin and thus apparently is ignored).

Your company is held responsible for everything that exits your piece of the Internet, likely more or less permanently. If your company sends messages that are construed as spam-such as unsolicited e-newsletters that do not comply with the expected opt-in procedures-your entire domain may be put in a block list or blacklist. If that happens, any mail server that subscribes to those blacklists will get no e-mail from your domain, not just the newsletters. (Most mail servers subscribe to at least one such list.) Imagine the effect if that happened. Wouldn’t that be a fun day at work?

It is possible to get onto blacklists in error. If you send a (fully compliant) newsletter and one recipient is too lazy to click on Unsubscribe (a surprising percentage are), the lazy user may report the newsletter as spam. Getting off such a list is a painful and tedious exercise, even if you do follow the rules. As a result, one member of your team should monitor public shared block lists and act immediately if you’ve been included-before more damage is done.

To ensure that mail is delivered-and not refused by other servers-permit only the domains you control to be used in outgoing e-mail messages. Anything else is forgery, even if the end user could legitimately use the e-mail address elsewhere. That is, a telecommuter might send a work e-mail message on the company server (user@company.com) but use her home ISP’s mail server (user@cox.net). This is a no-no. The only acceptable place to use a foreign address for a locally generated e-mail is in the Reply To.

What guidelines should my company use for setting e-mail policies?

Corporate culture sometimes trumps societal rules. But there are some policies that every enterprise should set for its users. Some of these are common netiquette, but the errors are particularly noteworthy because so many people use e-mail for business correspondence.

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?
• What are the major misconceptions about e-mail (incoming)?
• What criteria should I use in choosing an e-mail server (and the people to manage it)?
• Sure, sure, we care about Internet standards. Don’t we?
• What guidelines should the company use for setting e-mail policies?

Do not send a message to a large number of recipients in the To: or Cc: field. Doing so damages privacy by advertising everyone’s e-mail address, and such lists are difficult to read. Occasionally, a long To: list can cause problems with e-mail clients.

If your users commonly send messages to a large number of people, ask IT to set up distribution lists. On an ad hoc basis, individuals should address the message to themselves or to another primary recipient in the To: header, and place all the other recipients in the Bcc: (blind carbon copy) header. An IT department may need to alter the standard e-mail client configuration to make the Bcc: header available.

Determine how much personal e-mail is acceptable on a work account. Many companies set rules about the nature of messages that employees can send or receive in their business e-mail account. The rules may be arbitrary, capricious or simply stupid, but with an increasing need for enterprises to keep every message ever received…well, how much personal mail is your company willing to archive?

Few companies object to an employee sending a quick message to a spouse (“Can you pick up the kid at daycare?”). Most don’t mind if an employee signs up for an opt-in newsletter even if it’s only vaguely related to his job. However, some end users (especially those without broadband access at home) sign up for everything: a twice-daily horoscope, Bible lesson newsletter, dating hints. Not to mention the unending “Gosh, have you seen this joke?” messages.

You may want to consider requiring your employees to keep personal e-mail to a nonwork account, so that your e-mail administrators don’t have to deal with such things. If you do create a “no personal mail” rule, you must ensure that users can access their personal account from the office-or that corporate policy will be ignored.

Pay attention to message size. Many enterprise users unblinkingly attach huge files to e-mail messages, such as a 40MB PowerPoint presentation or a dozen photos. This slows down e-mail delivery at both client and server (particularly when the message is mailed to a company_all distribution) and consumes vast amounts of disk space. It’s especially annoying when the attachment is of a personal nature, such as family BBQ photos that the sender didn’t bother to resize.

Do not treat e-mail as though it’s a file transfer program. If your users typically exchange large files, you should set up shared network directories, an FTP server, an online file repository or another appropriate medium. Instruct your e-mail administrator to throttle the file size of messages sent or received, and to refuse messages over the limit. If possible, configure user e-mail clients to identify the message size before it’s sent, as an innocent user might drag and drop an attachment without any idea of the burden she’s about to inflict on others.

Encourage users to use plain text for messages instead of HTML or rich text. Users-including CIOs-love to send pretty messages with snazzy colors and multiple fonts. They imagine that an attractive layout makes a message easier to read. That isn’t necessarily the case, as the formatting in one e-mail client may display differently-or even be unreadable-on another. If it’s important to preserve layout and formatting, send a PDF document.

This topic can get your e-mail administrator’s shorts tied into a knot. Many feel strongly that e-mail always should be plain text, at least by default. HTML e-mail is insecure, since it does indeed work just like a Web page. Wrote one admin, “It’s not only stupid, but wasteful, and strongly signals that the sender is an ignorant newbie.”

Plain-text messages are also far smaller than any “pretty printed” e-mail messages. That’s especially true for users who (for reasons I’ve never fathomed) use Microsoft Word as an e-mail editor. The resulting “Hi, Mom!” message is six times bigger than its plain-text equivalent. All that, just so you can say “Thanks” in a pretty red font.

E-mail is every company’s “killer app.” Even a temporary interruption in service can bring business to a standstill. It behooves any enterprise to learn to manage its e-mail efficiently – especially since poor peer behavior can have dire consequences.