Email management definition and solutions

E-Mail Management topics covering definition, objectives, systems and solutions.

1 2 3 4 5 Page 4
Page 4 of 5
Table of Contents
div-hp-01.gif

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.

1 2 3 4 5 Page 4
Page 4 of 5
Learn how leading CIOs are reinventing IT. Download CIO's new Think Tank report today!