NIMS 3.0: As Easy To Manage as It Is To Use
Articles and Tips: article
01 Nov 2001
Without question, e-mail is today's essential business com- munications tool--the tool the press calls the "killer web application." Your organization (like every organization) needs its e-mail system. In fact, your organization's users, including you, probably can't imagine life without e-mail. E-mailing a message anytime to anyone, anywhere in the world is easier, less expensive, and more efficient than snail-mailing a letter or even using the phone.
Although you may love using e-mail, as a network administrator, you probably sometimes wish you could toss your organization's e-mail system (or at least offload the burden of managing it). The sad truth is that managing an e-mail system is typically not as convenient as using an e-mail system. For example, if you manage an e-mail system for a university or for an application or Internet service provider (xSP), you may have to create thousands of new e-mail accounts on at least a quarterly basis. Although this task is not an ordeal, it probably bores you (at best).
Whether or not you are subject to mass user-account creations, you or your coworkers may be faced with help-desk calls from new users. New users may call for help because they are unfamiliar with your system's e-mail client. This unfamiliarity coupled with resistance to change may prompt users to call simply to whine: "Why can't I just use Outlook?" Users may also call to ask why they can't access their e-mail from their dorm room or a web kiosk.
Users probably aren't the only ones complaining. IT managers in other departments within your organization may also periodically grumble about your e-mail system. Like users' complaints, managers' protests may stem from a resistance to change. For example, suppose the IT guys in the Biology department are familiar with NetWare but have to set up a Windows NT server to use your organization's e-mail system. Granted, as IT professionals, these managers won't complain at length about having to learn a new system. Nevertheless, you're going to hear at least a few moans.
Creating user accounts, fielding help-desk questions, and listening to grown-ups whine are tiresome tasks, but not the only costs associated with the demand for e-mail. Another arguably more troublesome cost is that this demand may result in an ever-expanding user base. This mushrooming user base, in turn, eventually exhausts the resources on your e-mail server--usually sooner rather than later.
The point is that most e-mail systems available today are ill-equipped to deal with the ever-expanding demand for e-mail. Novell Internet Messaging System (NIMS) 3.0, however, is one exception to this seeming rule: Released in September, NIMS 3.0 is a multiplatform, standards-based, Internet e-mail, calendaring, and scheduling solution built on Novell eDirectory. (If you use Novell GroupWise, you probably recognize GroupWise as a second exception to the aforementioned rule. In fact, both products are well-equipped to deal with the burgeoning demand for e-mail. However, GroupWise and NIMS 3.0 are very different products that meet the needs of very different e-mail markets. For more information, see "Why Does Novell Have Two Messaging Products?")
NIMS 3.0 is equipped to meet all of the varied demands associated with e-mail. For example, because NIMS 3.0 has eDirectory at its core and runs across multiple platforms, NIMS 3.0 meets your demand for a low-maintenance system. Because NIMS 3.0 supports Internet standards, it meets users' demands for a client-independent, accessible-from-anywhere system. Finally, having been built on eDirectory, NIMS 3.0 meets your organization's demands for a low-cost, scalable system. The bottom line is that managing NIMS 3.0 is nearly as convenient and efficient as using NIMS 3.0.
PLATFORM PREFERENCES
NIMS 3.0 was built from the ground up on eDirectory and, not surprisingly, supports the same server platforms that eDirectory supports. More specifically, you run NIMS 3.0 together with eDirectory (which is included on the NIMS 3.0 CD) on any of the following platforms:
NetWare 4.1x
NetWare 5.1 with Service Pack 3
Sun Solaris 2.7
Sun Solaris 8 with, Novell recommends, the Veritas file system
Red Hat Linux 6.1 and above with, Novell recommends, the 2.4 kernel
As you might expect, Novell plans to complete this multiplatform venture by porting NIMS 3.0 to Windows 2000 in the near future.
What you might not expect, however, is that NIMS 3.0 does not require high-end, expensive hardware. (For more information, see "System Requirements.") For example, to install NIMS 3.0 on a NetWare 5.1 or 4.1x server that supports up to 50 simultaneous connections, you need hardware with the following:
7 MB of free disk space (to hold NIMS 3.0)
32 MB of available memory (beyond the normal NetWare requirements)
Naturally, you need more memory for more connections--approximately 200 KB per Post Office Protocol (POP) connection and 300 KB per Internet Mail Access Protocol (IMAP) and web-based connections. You also need additional disk space for your message store, which holds users' mailboxes and messages.
Because NIMS 3.0 runs on multiple platforms and does not require high-end hardware, you can probably install NIMS on hardware you already have and on server platforms you already use. Being able to run NIMS 3.0 on existing hardware using a familiar platform is advantageous for several reasons: For example, by using existing hardware, you minimize implementation costs.
Furthermore, because NIMS 3.0 supports multiple platforms, you can set up a single system that consists of several distributed NIMS 3.0 servers running on a mix of server platforms. As a result, one department may run NIMS 3.0 on a Solaris server while another department may run NIMS 3.0 on Linux. With NIMS 3.0, you and your coworkers each can choose a familiar platform so that neither you nor your coworkers has to hassle with an unfamiliar platform.
CENTRALLY SIMPLE
Because NIMS 3.0 is built on eDirectory, managing NIMS 3.0 is convenient: For example, the User object ID in eDirectory is the user's e-mail ID. Rather than creating new accounts on a separate e-mail system for every existing and new user, you create only one account in eDirectory to enable users to access various network resources--including NIMS 3.0. (For more information about how User objects gain access to NIMS 3.0, see the "Agent Objects" section.)
In addition, with eDirectory at its foundation, NIMS 3.0 enables you to manage your entire NIMS system--hardware, software, users, and policies--from a central location. You don't have to wander from messaging server to messaging server (assuming you have more than one messaging server), nor do you have to wander from workstation to workstation.
Instead, you can manage the whole e-mail system from any workstation from which you can access either one of the two NIMS 3.0 management utilities:
The NetWare Administrator (NWADMIN) utility
Novell WebAdmin
The NWADMIN Utility
As you well know, NWADMIN provides a Windows-based management interface to eDirectory. You can use NWADMIN to manage NIMS 3.0 just as you use this utility to manage other network resources. The NWADMIN utility runs on any Windows 2000/NT/98/95 workstation. (See Figure 1.)
Novell WebAdmin
Novell WebAdmin is a browser-based application that enables you to access eDirectory using any browser that supports HTML 2 and above. (Virtually any browser available today supports HTML 2 and above, including Internet Explorer 3 and above.) Furthermore, NIMS 3.0 supports Secure Sockets Layer (SSL) over HTTP, ensuring secure administration from whichever browser you use. Using Novell WebAdmin, you can manage your e-mail system from pretty much anywhere--your office, your home, a coffee shop, or a hotel room. You need only a browser and an Internet connection to get the job done.
CONVENIENT CONFIGURING
Getting the job done--that is, managing NIMS 3.0--essentially boils down to creating and configuring eDirectory objects for NIMS 3.0. Of course, you will probably configure more objects than you create because the installation program that NIMS 3.0 provides automatically creates the eDirectory objects you need to get started. This installation program automatically creates the following objects (see Figure 1), which you then configure to meet your organization's specific needs:
An Internet Services container at the root of your eDirectory tree
A Messaging Server object within this Internet Services container
The Agent objects that you choose to associate with your messaging server
Template objects
Parent objects
Internet Services Container
The Internet Services container represents a collection of distributed NIMS 3.0 messaging servers in your eDirectory tree. There can be only one Internet Services container per tree.
The only configurable aspect of the Internet Services container is the Syslog. You configure the Syslog by specifying which events you want NIMS 3.0 to track so that you can later generate reports. You can use these reports to diagnose problems and fine-tune server performance.
The Syslog is a property of the Internet Services container and configurable in eDirectory when you run NIMS 3.0 on NetWare. If you run NIMS 3.0 on Solaris or Linux, you typically configure the Syslog by editing the /etc/syslog.conf file.
Messaging Server Objects
As you can guess, a Messaging Server object represents any messaging server in your NIMS 3.0 system. You can control various aspects of your NIMS 3.0 system by configuring Messaging Server objects. For example, if you have the necessary rights, you can configure a Messaging Server object to specify which user you want to manage this particular server.
You can also configure Messaging Server objects to enable servers to use SSL 2 or 3. NIMS 3.0 messaging servers use SSL to protect the information passed between servers or between servers and NIMS 3.0 clients.
If you want to enable users to encrypt their messages and thus secure messages that leave the NIMS 3.0 system, you can configure the Message Server object to allow X.509 client certification. Doing so enables the object's respective server to recognize client certificates, which clients can use to encrypt messages. (In other words, NIMS 3.0 does not encrypt messages. NIMS 3.0 supports message encryption, which is purely a client function.)
Agent Objects
Agent objects represent software processes that perform specific functions for your NIMS 3.0 system. (For a complete list of these Agents and brief explanations of their functions, see "Agent Actions.") You can control various aspects of your e-mail system by configuring the NIMS 3.0 Agent objects. For example, the Network Messaging Application Protocol (NMAP) Agent manages message stores and message queues. To control your message stores (and their associated queues), you configure various NMAP Agent object properties.
For example, in the NMAP Agent's Context property, you list eDirectory contexts of User objects to which you want to provide messaging services. (You can also disable messaging services for individual users within a listed context.) The first time a user within a listed context logs in to the NIMS 3.0 system, the NMAP Agent automatically creates a mailbox within the local message store for that user.
By setting the NMAP Agent's Mailbox Quota property, you can control the amount of disk space that these mailboxes occupy. You can set this quota on a system-wide or per-user basis. (If you enable the per-user option, you also need to set User objects' Disk Quota property.)
Furthermore, both the system-wide and per-user quotas can be active simultaneously. When both quota options are active, NIMS 3.0 checks the user quotas first. If a user's quota is defined, NIMS 3.0 uses that quota. If a user's quota isn't defined, NIMS 3.0 uses the system-wide quota for that user.
WHAT DO YOU WANT TO SEE TODAY?
Unlike previous versions of NIMS, NIMS 3.0 includes Template objects. (For a list of some other new features included in NIMS 3.0, see "First-Time Features.") Templates provide an HTML interface to the message store. In other words, templates dictate what the users see when they access their NIMS 3.0 account using the NIMS 3.0 web-based client.
By default, NIMS 3.0 includes two compiled web interface templates: the WebAccess and WebMail interface templates. (See Figure 2.) You can use one or both of these templates or create templates of your own. Creating your own templates enables you to generate "any look and feel on the web front-end you want," explains Novell product manager Lynn Madsen.
To create a new template, you must modify HTML code to define the layout you want. You then compile the template elements and associate the resulting template with the Template object that will represent this compiled template in eDirectory. (NIMS 3.0 includes a compiler and its documentation.)
PARENTS TELL CHILDREN WHAT TO DO
After you create your templates, you can use Parent objects (also new in NIMS 3.0) to enable different sets of users in the same NIMS 3.0 system to choose from different sets of templates. For example, suppose you create a total of six templates. You may enable users in the Student context to choose from Templates 1, 3, and 5, while enabling users in the Faculty context to choose from Templates 2, 4, and 6.
In fact, by using Parent objects, you can ensure that different sets of users gain access not only to different templates but also to entirely different classes of service. You create and configure Parent objects in your eDirectory tree and then associate User objects--which are figurative children--with these Parent objects.
The Parent objects thereafter tell their "children" what to do. That is, the features or functions that you enable or disable for a Parent object are thereafter enabled or disabled for this Parent object's children.
For example, suppose that you set up NIMS 3.0 for use at a university. You may create two Parent objects for the two distinct populations at your university: students and faculty. For students, you may create a Parent object called Restricted, and for faculty, an object called Everything.
In the Restricted Parent object, you may enable users to have only HTML access to their mailboxes. You may also allow users associated with the Restricted Parent object to select from only two of the five Template objects you have created for your system.
You may further specify that you want students to create messages no larger than 2 MB and that students' mailboxes never exceed 5 MB of disk space. You may also disable the autoforwarding and autoreply features. (The autoforwarding feature enables users to configure their NIMS 3.0 mailbox to automatically forward their mail to another e-mail address. The autoreply feature enables users to set up an automated response for periods of time when they are not monitoring their e-mailboxes, such as vacation periods.)
In the Everything Parent object, you may enable not only HTML access but also access via POP and IMAP clients. You may also allow faculty users to choose from any of the five Template objects you have created for your system. You may further specify that faculty users associated with the Everything Parent object be allowed to create messages as large as 5 MB and to have mailboxes that consume as much as 10 MB of disk space. Finally, for faculty users associated with the Everything Parent object, you may enable the autoforwarding and autoreply features.
You may be relieved to learn that you can configure the same features for User objects that you can configure for Parent objects. Individual User object definitions override Parent object definitions.
As a result, you can use Parent objects to apply general policies and then use User objects to apply individual exceptions, rather than having to create a Parent object for each exception. In other words, through its Parent objects, NIMS 3.0 enables you to easily ensure that different user populations get no more or less than precisely what they need.
STANDARDS SUPPORT FOR CLIENT INDEPENDENCE
NIMS 3.0 also ensures that users get what they want. For example, because NIMS 3.0 supports messaging standards, users can access their NIMS 3.0 e-mailboxes by using the NIMS 3.0 web client or any e-mail client that also supports these messaging standards. To be specific, NIMS 3.0 supports all major standards related to messaging, including POP3, IMAP4, HTTP, Simple Mail Transfer Protocol (SMTP), and Lightweight Directory Access Protocol (LDAP). (For more information, see "NIMS' High Standards.")
Hence, assuming you enable POP and IMAP access, users can access their NIMS 3.0 mailbox using any POP3 or IMAP4 e-mail client, including Outlook and Outlook Express, Netscape Communicator, and the GroupWise, Eudora, and Pegasus clients.
Conversely, either you or your users can configure the NIMS 3.0 Proxy Agent to routinely retrieve messages from users' other e-mail accounts. This way, users can consolidate their various e-mail accounts, which they can then access using the client of their choice. And if users choose the NIMS 3.0 web client, they can access all of their e-mail from anywhere they have access to a browser and an Internet connection.
Either you or your users can take the necessary steps to enable this proxy feature, assuming you have created a Proxy Agent in eDirectory. If you want to enable a user to receive messages from other e-mail accounts in his or her NIMS 3.0 inbox, you do so by configuring the User object's Proxy Setting property. Alternately, you can allow users to configure the proxy settings for their own NIMS 3.0 e-mailbox. Users configure the proxy settings for their own e-mailbox by completing the Proxy Settings on the Options page in the NIMS 3.0 WebAccess interface.
Configuring a Proxy Agent is simple. You can try it out for yourself by visiting www.myrealbox.com. (See Figure 3.) Myrealbox is Novell's online demonstration of NIMS and enables anyone to sign up for a NIMS mailbox. At the time this article was written, myrealbox.com was running NIMS 2.6. However, by the time you read this article, myrealbox.com will be (or soon will be) running NIMS 3.01.
After you have signed up for an account, click Options, and then click Proxy Settings. (See Figure 4.) You can then enter the host name of the ISP's POP or IMAP server from which you want NIMS to retrieve mail. You also need to enter your username and password for each e-mail account. Finally, you can either select the Leave on Server field or keep this field unselected. When you select the Leave on Server field, NIMS leaves a copy of the message on the server from which NIMS retrieves your e-mail messages.
PICK YOUR PREFERENCE
The Options page also enables users to set up their NIMS 3.0 e-mail accounts as they prefer. From this page, users can set web-client-specific features, including language and autosignature features. Users can also set client-independent features, including the proxy, autoforward, autoreply, and time zone features.
You can check out a couple of these features for yourself. For example, go back to the Options page on myrealbox.com, and scroll down to the WebAccess Settings. (See Figure 5.) You will notice in this section a field for Language. From the Language field, you can choose from a pull-down list of 26 supported languages.
Try it out. Select Chinese or Russian, and then click Save. Within seconds, the interface--help files included--appear in the language you selected.
In the Time and Date Settings, you can change the time zone. The Time Zone option works as easily as the Language option and is particularly handy for mobile users.
For example, suppose you're traveling in France, but you have scheduled several teleconferences and phone interviews in your normal time zone. When you land in Paris, you simply select the correct time zone from the list of 74 time zones, and all of your scheduled appointments will appear in the correct time for your new location--regardless of the client you use to access your NIMS 3.0 e-mail account. (See Figure 5.)
CHECK YOUR CALENDAR
If you have used NIMS in the past, you may be confused by that last paragraph. You may mistakenly assume that NIMS 3.0 can't change your scheduled appointments because it doesn't know about your appointments. After all, versions of NIMS prior to NIMS 3.0 don't include a calendar or scheduling feature. NIMS 3.0, in contrast, does include this feature.
NIMS 3.0 supports the Internet Calendaring (iCalendar) standard. (For more information about the iCalendar standard, read Request for Comments [RFCs] 2445 through 2447. You can download these RFCs from http://www.rfc-editor.org/.) Using iCalendar is optional, and you enable that option by creating a Calendar Agent when you install NIMS 3.0.
By supporting iCalendar, NIMS 3.0 provides users with access to a calendar that they can use to schedule meetings, interviews, conferences, events, vacations, or anything else they might ordinarily schedule. Like other calendar-scheduling applications, NIMS 3.0 also supports Tasks and Notes, enabling users to maintain a to-do list and to jot down random notes.
You can check out the new NIMS 3.0 calendaring feature for yourself by visiting www.myrealbox.com. Assuming myrealbox.com is running NIMS 3.0 at the time you sign up for an account, you will be given the option to choose between two interface templates--WebAccess and WebMail--which are the default templates included with NIMS 3.0. Select the WebAccess template.
Not many e-mail applications currently support iCalendar. In fact, NIMS 3.0 is one of the first applications to do so. However, as more e-mail clients support iCalendar, NIMS 3.0 users will be able to use any of these clients to access the calendar they create from the NIMS 3.0 client.
For example, the new Outlook 2002 client in Microsoft Office XP supports iCalendar. When users schedule an appointment in Outlook 2002, they can view, accept, and decline that appointment in the NIMS 3.0 web client and vice versa. (See Figure 6.) If users add an event to their calendar in NIMS 3.0, they can view, accept, and decline that event in Outlook 2002 and vice versa. If users jot down an upcoming birthday in Outlook 2002, they can . . . You get the idea.
Through its support for iCalendar, NIMS 3.0 provides some of the features that users may otherwise miss when your company opts for a web-based, mostly e-mail application rather than feature-rich collaboration software, such as Novell GroupWise, Microsoft Exchange, or Lotus Domino. (For more information about collaboration software versus mostly e-mail software, see "Why Does Novell Have Two Messaging Products?")
MEETING THE DEMANDS OF ORGANIZATIONS
The fact that an e-mail system meets users' needs for an accessible, client-independent system probably means little to your boss or whomever else in your organization is responsible for the bottom financial line. These people--I'll call them the powers-that-be--care primarily about cost and return on investment.
For example, the powers-that-be in your organization no doubt care about how many users one NIMS 3.0 server can support. Universities and xSPs want to know whether they're going to have to foot the bill for another server with every influx of new users. The good news is that NIMS 3.0 is built on eDirectory, which holds as many as one billion objects per tree, making it the most scalable directory in the world. Not surprisingly, NIMS 3.0 is the most scalable e-mail system available.
A single NIMS 3.0 server can host 100,000 or more users. In fact, until recently, a single Dell PowerEdge 6350 (with 2 GB of RAM and one 550 MHz Pentium III Xeon Processor) supported 150,000 users on www.myrealbox.com. The site is now hosted on three Compaq servers. "Not that three servers are necessary," Madsen points out. On the contrary, "one server would do." However, Novell implemented myrealbox.com on three servers "in order to test certain distributed aspects of NIMS," Madsen explains.
Naturally, the actual number your NIMS 3.0 server supports will vary, depending on the number of simultaneous connections. For example, Novell's projections regarding one server's support for 100,000 users is based on the assumption that no more than 3 percent of these users will be connected simultaneously.
According to Novell product marketing manager Richard Bliss, NIMS' scalability makes it a particularly attractive messaging option not only to universities and xSPs but also to governments. In fact, one Central American country already runs NIMS. At the time this article was written, a European country had just requested price estimates for a NIMS system, which the country was hoping to roll out to its population of nine million.
"And that's not the largest bid we've had a request for," Bliss claims. One worldwide consulting firm requested pricing estimates for 10 million users, says Bliss, adding that a religious organization had requested an estimate for 11 million users. The point is, NIMS 3.0 (and earlier versions), as several organizations have already recognized, is a messaging product that can scale to the tens of millions.
Of course, having 100,000 users on a single server or millions of users distributed across several servers is not particularly appealing if that system isn't a stable one. Novell recognizes this fact and designed NIMS 3.0 to be as reliable as it is scalable.
NIMS 3.0 has been tested processing more than 1.1 million messages per day on low-end hardware and experienced no delivery failures or errors. Specifically, Novell tested NIMS 3.0 on three Compaq servers: One server had 1 GB of RAM and a 450 MHz Pentium III processor, and the other two servers had only 512 MB of RAM and Pentium II processors.
NIMS 3.0 also enables you to distribute services such as IMAP, SMTP, POP, and message stores across several NIMS 3.0 messaging servers, which means you can protect your messaging system's critical processes from single points of failure. As a result, your users can continue to send and receive e-mail uninterrupted--even if one of your servers fails.
For the powers-that-be within your organization, more users on fewer servers and fewer system downtimes mean, simply, more money in the bank.
What Does the Birdie Say?
Your organization isn't necessarily cheap--well, maybe it is. Whether or not you can call your organization cheap, all organizations are looking to get the biggest return possible on every dollar spent. Your organization wants proof of real savings rather than intangible probabilities, such as the promise of saving money because NIMS 3.0 is, as Bliss says, "manageable at a level that currently just does not exist."
In other words, your organization wants to know how much NIMS 3.0 costs. At U.S. $9 per user license, NIMS 3.0 is 90 percent less expensive than messaging-collaboration systems, which typically cost about U.S. $100 per seat.
Ultimately, It's All for One
Cost aside, all of the features in NIMS 3.0 ultimately benefit you, regardless of the users and organizational powers-that-be who also benefit from these features. For example, the fact that NIMS 3.0 is scalable and reliable saves your organization money and ensures uninterrupted access to its essential communications tool. NIMS' scalability and reliability benefit you because they mean fewer servers to maintain and fewer crises to handle
The NIMS 3.0 features that directly benefit users also indirectly benefit you. For example, the fact that users can access their e-mail using the client of their choice eliminates a lot of help-desk calls. Furthermore, you don't have to install an e-mail client on any user's desktop because users can access NIMS 3.0 using either only their web browser or whatever client they already have installed on their desktop.
Of course, some NIMS 3.0 features clearly benefit you directly (and users and your organization only indirectly). For example, NIMS 3.0 enables you to manage an entire e-mail system from a single, central location--and to choose this location. Users and, arguably, your organization don't really care (even if they should) that managing NIMS 3.0 is this simple and flexible.
The features in NIMS 3.0 thus benefit you as well as your users and your organization for two main reasons: One, NIMS 3.0 is scalable, reliable, flexible, and as easy to manage as it is to use because Novell designed NIMS 3.0 with real administrators, real users, and real organizations in mind. Two, NIMS 3.0 is scalable, reliable, flexible, and as easy to manage as it is to use because it is built on eDirectory. And eDirectory is the key to the success of NIMS 3.0 and all of Novell's Net services software, which simplifies, accelerates, and secures access to your network resources.
Linda Kennard works for Niche Associates, an agency that specializes in writing and editing technical documents.
Agent Actions
NIMS Agents are software processes that perform various functions for your Novell Internet Messaging System (NIMS). Some of the agents are required, while others are optional. Below is a list of all NIMS Agents included on the NIMS 3.0 CD:
|
Agent
|
Action
|
Required or Optional
|
|
NMAP Agent |
Manages the message store and message queue; also provides IP access to the message store and message queue for the other NIMS agents. |
Required. |
|
SMTP Agent |
Transfers messages to and from the Internet. |
Required if your NIMS system will send messages across the Internet or between messaging servers. |
|
POP Agent |
Provides mailbox access for users with any POP3 e-mail client. |
Required if your NIMS system will support POP3 e-mail clients. |
|
IMAP Agent |
Provides mailbox access for users with any IMAP4 e-mail client. |
Required if your NIMS system will support IMAP4 e-mail clients. |
|
WebMail Agent |
Provides mailbox access from any web browser. |
Optional. |
|
Address Book Agent |
Allows users to look up e-mail addresses in the NIMS system-wide address book. |
Optional. |
|
AutoReply Agent |
Allows users to set up an automated e-mail response when they are not monitoring their mailboxes. Also enables users to automatically forward their messages to anothere-mail address. |
Optional. |
|
Rule Agent |
Allows users to set up more complex automated processing of messages |
Optional.. |
|
Proxy Agent |
Allows users to consolidate messages from other POP3 or IMAP4 e-mail accounts into their NIMS mailboxes. |
Optional. |
|
Alias Agent |
Enables your NIMS system to recognize usernames in a variety of formats, such as LKennard@abc.com or L_Kennard@abc.com. |
Optional. |
|
AntiSpam Agent |
Blocks messages from specified users or domains. |
Optional. |
|
List Agent |
Enables your NIMS system to function as a list server. Also allows eDirectory container objects to function as mailing lists. |
Optional. |
|
Finger Agent |
Allows NIMS users to provide customized responses to finger requests from other users. |
Optional. |
|
Connection Manager |
Tracks IP addresses of authenticated senders. |
Required to use the SMTP Agent's Do-SMTP-After-POP feature. |
|
Modular Web Agent |
This interface template engine enables you to create templates that dictate the web interface. Users choose from what-ever templates to which they have rights, and the ModularWeb Agent first finds the eDirectory Template object andreturns the interface defined there to the user. |
Optional. |
|
Calendar Agent |
Allows users to use the iCal Scheduling and Calendaring feature. |
Optional. |
First-Time Features
The following features are available for the first time in the recently released Novell Internet Messaging System (NIMS) 3.0:
Fully customizable web interface (via Modular Web Agent and Template objects)
Class-of-service management (via Parent objects)
Calendaring and scheduling capabilities (through iCalendar support)
Tasks (To Do Lists) and Notes (through iCalendar support)
User-selectable time zones
Enhanced web interface
Clickable URLs and e-mail addresses
Embedded HTML message viewing
Ability to create groups in personal e-mail address book
Enhanced List server capabilities (which, among other things, enable users to subscribe to a list from which they only can receive (but not contribute) information
Antivirus integration
Enhanced spam detection on the back end
NIMS' High Standards
NIMS 3.0 supports all of the major messaging-related Internet specifications, which means that it complies with the current Request for Comments (RFC) documents for these specifications. RFCs are published specifications that are on track to becoming standards, as designated by the Internet Engineering Task Force (IETF). (For a complete list of RFCs and an indication of where each is in the IETF standardization process, see www.rfc-editor.org/rfcxx00.html#STDbyRFC.)
Some of the specifications that NIMS 3.0 supports already have been officially designated as standards by the IETF. The remaining supported specifications are in the process of becoming official IETF standards. In the meantime, these soon-to-become-official standards have been accepted already industry wide as de facto standards.
Post Office Protocol 3 (POP3), RFC 1939, IETF Standard (STD) 53
E-mail clients that support POP3 use this protocol to retrieve messages from e-mail servers. When a client retrieves a message using POP3, the protocol typically downloads the message to the e-mail client and then deletes that message from the user's mailbox on the server. Consequently, POP3 e-mail clients must store everything locally: user preferences, folders, and all retrieved messages. While POP3 conserves space on the messaging server, it enables users to access their folders and retrieve messages only locally, from the workstation running the POP3 e-mail client.
Internet Mail Access Protocol (IMAP 4), RFC 2060, Proposed Standard
E-mail clients that support IMAP4 use this protocol to retrieve messages from e-mail servers. As with POP3, when a client retrieves a message using IMAP4, the protocol downloads the message to the local e-mail client. However, unlike POP3, IMAP4 leaves a copy of this message in the user's mailbox on the server. The upside to this is that IMAP4 enables users to access their messages from anywhere they have access to a browser and an Internet connection. The downside is that users' server-side mailboxes can consume too much of the messaging server's disk space. Fortunately, NIMS 3.0 supports mailbox quotas so that you can restrict the size of users' mailboxes.
HyperText Transfer Protocol (HTTP) 1.1, RFC 2616, Draft Standard
Because it supports HTTP 1.1, NIMS 3.0 enables users to access their mailboxes via the web. The NIMS web-based client enables users to send and receive mssages from anywhere they have access to a web browser and an Internet connection.
Support for HTTP 1.1 also enables you to manage NIMS 3.0 using WebAdmin. WebAdmin is a web-based administrative tool that enables you to manage the NIMS 3.0 system from anywhere you have access to a web browser and an Internet connection.
Simple Mail Transfer Protocol (SMTP), RFC 821, IETF STD 10
E-mail clients use SMTP to send messages to e-mail servers. E-mail servers use SMTP to exchange messages. Because it supports SMTP, NIMS 3.0 servers are compatible with other Internet e-mail servers and most TCP/IP systems. The NIMS 3.0 SMTP Agent passes inward and outbound messages between your NIMS system and the Internet.
Multipurpose Internet Mail Extensions (MIME), RFCs 2045, -46, -47, and -49, Draft Standards
MIME is a specification for formatting non-ASCII messages so that they can be sent over the Internet. Because the NIMS 3.0 web client supports MIME, it can send and receive graphics, audio, and video files via the Internet mail system.
Internet Calendaring and Scheduling (iCalendar), RFCs 2445, -46, -47, Proposed Standard
iCalendar is a specification for providing and deploying interoperable calendaring and scheduling services for the Internet. Because NIMS 3.0 supports iCalendar, you can schedule appointments in NIMS 3.0 and view, accept, and decline iCalendar appointments sent to you from other clients that also support iCalendar.
Secure MIME (S/MIME), RFC 2632, -33, and -34, Proposed Standard
S/MIME is a version of the MIME specification that supports encryption of e-mail messages. S/MIME is based on RSA's public-key encryption technology. Because NIMS 3.0 supports S/MIME, users who use the NIMS 3.0 web client can exchange encrypted e-mail messages with other e-mail clients that also support S/MIME.
Lightweight Directory Access Protocol 3 (LDAP3), RFC 2589, Proposed Standard
LDAP3 is a set of protocols used for accessing information directories that is based on (but significantly simpler than) the X.500 standard. Applications that support LDAP3 can access LDAP3 directories such as Novell eDirectory, Netscape Directory Server, and Microsoft Active Directory.
NIMS 3.0 supports a read-only subset of LDAP3 through its Address Book Agent. By communicating with this Address Book Agent, any LDAP3-compliant e-mail client, such as the NIMS WebMail client, can access address book information in eDirectory. Because the Address Book Agent directly references eDirectory for user information, its information is always as current as eDirectory.
You can control how much personal information appears in an Address Book entry by configuring User or Group objects' Privacy properties. Alternately, you can enable users to choose how much personal information they want the Address Book Agent to share with other NIMS users. To control their Address Book information, users select Preferences in the web-based NIMS client and then choose General Settings. From there, users select Privacy. Users can then set the Privacy field to one of the following:
None. When a user chooses None (in other words, opts for no privacy), address book queries about this user will reveal all general information about this user, including his or her first and last name, e-mail address, and phone number.
Limited. When a user chooses Limited, address book queries about this user will reveal only his or her e-mail address.
Unlisted. When a user chooses Unlisted (in other words opts for maximum privacy), address book queries about this user will reveal no information.
Transport Layer Security version 1 (TLSv1), RFC 2246, Proposed Standard
TLSv1 was developed by the IETF to replace the Secure Sockets Layer (SSL) protocol developed by Netscape. NIMS 3.0 actually supports both TLS and SSL versions 2.0 and 3.0 through its use of the OpenSSL toolkit. (For links to TLS and SSL specifications, see www.openssl.org/related/ssl.html.)
The Open SSL toolkit (and related documentation) is a commercial-grade, full-featured, and open source toolkit that implements SSL v2/v3 and TLS v1 and also includes a full-strength, general-purpose cryptography library. The toolkit was developed and continues to be enhanced by a worldwide community of volunteers, who work together on this project, which is appropriately called the OpenSSL Project. (For more information, visit the OpenSSL web site at http://www.openssl.org/.)
Because it supports SSL v2/v3 and TLSv1, NIMS 3.0 secures e-mail transmissions between clients and NIMS servers, which in turn ensures the security of remote administration, user self-administration (such as changing passwords), and user authentication over the Internet.
System Requirements
To run Novell Internet Messaging System (NIMS) 3.0 on a NetWare platform, you must have hardware that meets the following minimum requirements:
7 MB of free disk space (to hold NIMS 3.0)
32 MB of available RAM
Disk space for your company's message store
To run NIMS 3.0 on a Solaris platform, you must have hardware that meets the following minimum requirements:
20 MB of free disk space (to hold NIMS 3.0)
NDS for Solaris installed
Disk space for your company's message store
To run NIMS 3.0 on a Linux platform, you must have hardware that meets the following minimum requirements:
20 MB of free disk space (to hold NIMS 3.0)
NDS for Linux installed
Why Does Novell Have Two Messaging Products?
If you're one of Novell's 26 million GroupWise users and have recently heard or read about Novell Internet Messaging System (NIMS), you may be wondering why Novell has two messaging products. We caught up with Novell product marketing manager Richard Bliss and posed this question to him.
Bliss' surprisingly logical answer boils down to this: Novell has one messaging product for each of two distinct messaging markets. GroupWise lives in the market space controlled by organizations' demands for feature-rich collaboration applications, also called groupware (or workgroup) applications. NIMS, in contrast, fits organizations' demands for bare-essentials e-mail applications, which comprise the second messaging market.
Collaboration applications are more mature than the relatively new fundamental e-mail applications and, not surprisingly, widely known and used, particularly in the business world. In fact, when you say "e-mail application," most users immediately think of one or all of the three applications that dominate the collaboration space: Novell GroupWise, Microsoft Exchange, and Lotus Domino.
Above all else, collaboration applications were designed to enable groups of coworkers, often at different sites, to work together on a project with the help of network technologies. These applications typically provide much more than e-mail alone--enabling users to create, store, share, and act on information by integrating other non-messaging applications, including word-processing applications.
The 12-year-old GroupWise is a strong player in the collaboration space for several reasons, including the following:
GroupWise runs on multiple platforms, namely NetWare and Windows 2000/NT.
GroupWise extends the collaboration zone to what are being called deskless workers, that is, workers who spend most if not all of their time away from a desk and, consequently, may not have a PC. GroupWise enables deskless workers to access their GroupWise Universal Inbox (which integrates e-mail, fax, and voice-mail messages) via the web or wirelessly using cellular phones or handheld devices. (For more information about deskless workers, see "Novell Brings Messaging to the Deskless Work Force.")
GroupWise is not subject to the same viruses that plague Exchange and Outlook e-mail clients.
Most important, GroupWise offers a stable platform on top of which organizations can build additional collaboration services.
GroupWise and other collaboration applications meet specific workgroup needs, but not every organization needs all of the features these applications offer. In many cases, some or all of an organization's users need e-mail alone. In this case, a collaboration application is overkill. Simply put, buying a collaboration application when you need only e-mail is like buying a dining room suite when you need only a chair.
When some or all of your company's users want or need only e-mail, bare-essentials e-mail applications, such as NIMS, are a better fit. Above all else, these essentially e-mail applications are designed to enable the free exchange of messages over the Internet. As a result, web access to e-mail is not a feature these applications have recently added to their core product. Enabling web access to e-mail is more or less the point of these products.
Several players compete in this Internet e-mail market, including iPlanet, OpenWave, Sendmail, and Mirapoint. While each of these service providers' or vendors' products provides Internet e-mail, NIMS stands out for several reasons:
In addition to e-mail, NIMS offers calendaring and scheduling features through its support of iCalendar. (For more information about the iCalendar standard, see "NIMS' High Standards.")
NIMS was built from the ground up on Novell eDirectory, which means, among other things, that NIMS scales well and is easy to set up and manage.
At U.S. $9 per user license, NIMS is available for one-tenth the cost of collaborative applications.
NIMS is client-independent.
Some of the other e-mail applications can compete in some of these categories, but no other e-mail application can compete in all of these categories.
So why does Novell have two e-mail products? "Because there are two dynamic e-mail markets," Bliss sums up. Whether your organization needs a collaboration application alone, an Internet e-mail solution alone, or a combination of both, Novell is there to meet your messaging needs.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.