How can you select the right messaging system for your business? In 10 easy steps, Hallett German and Beth Cohen outline the criteria needed to evaluate messaging systems.
Life was good. Acme Widgets had ten employees and modest but steady growth. Tanya Hunter, administrative assistant and part-time IT staff, implemented an e-mail system for the company. After reading some trade magazines and the recommendations of a couple of mailing lists, the package she chose handled both text and binary attachments, was easy to install and support, and was free.
Fast-forward ten years, and everything has changed. Acme Widgets has grown to 250 employees, the merger with Spacely Sprockets is proceeding, and the company is embarking on an exciting new phase
Except...remember that old e-mail system? Acme is still using it, but Spacely Sprockets is using an equally antique but different legacy e-mail system. Potential business deals are lost. Customers are complaining that Acme Widgets is unresponsive. The CEO's administrator is faxing important documents to key partners rather than trusting e-mail. The support infrastructure has grown to two full-time e-mail administrators who are overworked trying to cope with:
- Babying temperamental servers unable to handle the growing messaging volume. A large part of the growth is increasingly large attachments and unsolicited e-mail (commonly known as spam).
- Unstable network connections to both servers and the outside world caused by broadcast storms
- Endless problems debugging mail attachment issues (e.g. messaging client does not understand attachment type, attachment type understood but not decoded, corrupt attachments, etc.).
So, obviously, it was time to take action. Tanya Hunter, now CIO, is researching a unified messaging system
for the merged company. The system must be stable, secure, cost-efficient, fast and scalable. Power users want full support for various Internet messaging standards. Can she find products that meet all these requirements? Yes.
Even though Tanya and Acme Widgets are obviously not real, the problems we've outlined are very real for many companies, so a discussion of messaging solutions can be applied to many situations. With a good messaging implementation, your company can also enjoy:
- Productivity increases
- Stable servers
- Seamless attachment translation
- Proactive viruses and spam protection
First, let us learn something about choosing a reliable and appropriate messaging system for your company. Later we will also delve into some of the details of the messaging protocols.
Choosing a messaging system for your company is a major decision that you will need to live with for a long time. Learning as much as you can in advance about your options and company requirements before you choose will avoid potentially costly mistakes. As you read each of the ten steps listed below, can you answer them for
your company? Once you have the answers, your decision will be that much easier.
1. Ease of Administration -- Does the system have a low TCO (Total Cost of Ownership)? Automated
installs, proactive monitoring/reporting, and logging, virus/spam management, etc. will help make your administration job easier. How many hours need to be dedicated to administrative tasks such as
backup, system tuning, message database compression, account/mailbox creations, renames, moves, and deletion each week? Are new skills are required for mail administration? For example, the learning curve for SMTP administrators using sendmail for e-mail operations is extremely high.
2. Scalability -- You will need to create message profiles (how many messages a day, size of attachments, etc.) and simulate the load on the proposed system. Will the system support your growing needs? What
is the average messaging load now? Do you anticipate a large increase?
3. Security -- Does the system have authentication checking? Is secure e-mail available using public keys? Can access control list be used to disable/enable user access to various features?
4. Available Features -- Proprietary messaging system will always have more features than a simple POP/IMAP client. How many of them will be helpful to end users? How many will just cause support headaches because they are confusing or allow users to do potentially harmful actions such as deleting their mailbox or e-mailing 1,000 users at once?
5. Integration with other applications -- Can the system integrate with your existing applications such as directories, document management, ticketing systems, newsgroups, workflow, collaboration, calendaring
and scheduling etc? Is the integration seamless from the user perspective? Does the application have the ability to send pages, faxes, etc? What format are the messages? Is there a maximum length? Are they
automatically routed to the correct persons or is manual intervention required? Can inbound/outbound faxes be tracked separately from the regular e-mail?
6. Mailing Lists -- Do you have a need for extensive mailing lists? Can you add addresses external to your company? Will you as the administrator need to manage them or will you have the users manage their own lists? This can be a very time consuming task for an administrator.
7. Vendor Relationship -- A proprietary solution ties you to one vendor. If that vendor goes out of business or drops the product line, you will be forced to change solutions. Ask anyone who purchased Lotus cc-mail. If you choose an open standard such as POP or IMAP client/server, you can easily replace either the client or server with much less company disruption.
8. Internet Standards Compliance -- Does the system handle present and future Internet standards? What proprietary "additions" to the standards are supported?
9. Archiving -- How far back can you retain messages? How do users retrieve and access these archives?
10. Application Program Interfaces (APIs) -- If you have a very large or specialized requirement you might have need to customize the client. Does the system have the ability to do this?
Next: Internet E-Mail Standards
This article was originally published on Friday Dec 27th 2002
In its simplest form, a messaging system allows two users to send and receive written communications from each other. Two hardware/software components are involved, the client program or message receiver and the server or message transport mechanism:
- The client downloads e-mail and allows the user to read messages on their local machine. The messaging client ideally should be available across hardware and software platforms for reduced maintenance costs
- The server relays e-mail from other servers and oversees the downloading of messages to the client. E-mail systems all use a "store and forward" system of transport.
Regardless of which messaging system you select, it will need to incorporate Internet messaging standards. Internet messaging standards address the following seven challenges:
Challenge 1: Sending a non-text or "complex" message. MIME (Multi-purpose Internet Mail Extensions) was created to handle complex messages. This complexity may refer to attachments (sounds and movies), different languages, or different hardware/software platforms. The basic Internet message standard is described in RFC 822, also known as "rfc822 format." A coding mechanism named base64 is used to encode attachments. Here
is a typical text MIME header:
Content-Type: text/plain; charset="us-ascii"
The header information includes the MIME version, a type of text and a subtype of plain. It also tells you that the US ASCII character set is used. The sample has only the bare minimum of information that can
be incorporated. Common MIME types include text, image, audio, video, and application (which would include binary files and Postscript files).
Challenge 2: Messaging and security. Most messaging clients support S/MIME (Secure Multipurpose Internet Mail Extensions) an Internet standard developed by RSA to handle privacy, data integrity, and authentication. It sends secure e-mail using digital signatures and encryption.
Challenge 3: Sending mail between local clients. There are three types of relationships between servers and clients:
- Online -- Messages are left on the server where they can be accessed and manipulated by one or more users.
- Offline -- Messages are downloaded from the server and placed on the client device.
- Disconnected -- A copy of the messages are downloaded from the server to the client. However, a copy of the messages remains on the server. The client periodically connects with the server to catch up with new messages.
The two commonly used Internet mail standards are POP and SMTP. POPMail or POP3 (Post Office Protocol, version 3) is simpler to maintain and the more popular of the two. POPMail supports offline mode
and folder management (of one folder). IMAP (Internet Messaging Access Protocol) provides message
management features closer to those found on many proprietary systems. IMAP supports offline mode, online/disconnected mode, folder management (multiple folders), and shared mailboxes (such as group messages, news groups, help areas).
Challenge 4: Moving mail from server to the Internet. SMTP (Simple Mail Transfer Protocol) uses the TCP/IP protocol to send text messages between servers (also called Message Transfer Agents, or MTAs) across the Internet.
Challenge 5: Overcoming SMTP limitations. SMTP has been around for close to 20 years so it has
some limitations, so two protocols have been created to enhance SMTP functionality.
ESMTP (Extended SMTP) includes delivery service notifications (return receipt), enhanced error codes, and size limitations on large messages.
With ESMTP, you can block messages based on size, or forward a note back to the sender not to send large files again.
Challenge 6: Looking up the network addresses of the mail servers. DNS (Domain Naming Service) is a distributed database filled with resource records of public Internet servers (including mail servers)
their names and IP addresses. The major implementation of DNS called BIND (Berkeley Internet Name Domain) includes records specifically used for mail transport.
Challenge 7: Looking up messaging recipients. Before LDAP (Lightweight Directory Access Protocol), the
complexity of server setup and administration kept many companies from implementing electronic directories. Now LDAP has simplified things so that directories are available for messaging recipient lookup, authentication, and many other uses.
We have just touched the surface of the intricacies of messaging systems. At the end of the day, will the company be more productive with the new system? Only you can answer that for your company, but if you ask yourself a few simple questions to when evaluating systems, you will save yourself a lot of
- What are the business drivers for the new system?
- Will the employees experience higher productivity and job satisfaction because to the better tools and
integration with desktop applications?
- What is the current and projected messaging traffic for the company?
- How much training is needed to bring my users and administrators up to speed?
- If we merge with another company, how easily can we consolidate both messaging systems?
- How much time will my administrators be spending on firefighting with the new system? How much time on
DNS Resources Directory
IMAP vs. POP
Refrigerators with e-mail!
Hallett German is an IT consultant who is experienced in implementing stable IT infrastructures with an emphasis on electronic messaging and directories. He is the founder of the Northeast SAS Users Group and former President of the REXX Language Association. He is the author of three books on scripting languages. Beth Cohen is president of Luth Computer Specialists, a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields including architecture, construction, engineering, software, telecommunications, and research. She is currently writing a book about IT for the small enterprise and pursuing an Information Age MBA from Bentley College.
See All Articles by Columnist Beth Cohen