Resource objects represent shared resources such as conference rooms, training facilities, equipment, and so forth. By creating the Resource object in a supported NMAP context, the resource automatically has its own mailbox and calendar. eDirectory is a critical element in the NetMail messaging system. During installation, NetMail extends the eDirectory schema to include objects for each component in the NetMail messaging system. It also adds attributes to existing Directory objects, such as Container, User, and even Server objects. The NetMail objects and attributes store all of the system configuration parameters for NetMail---the messaging server and agent settings, supported Internet domains, and even individual user settings are stored in eDirectory. In fact, the only thing not stored in eDirectory are the messages.
Storing user information and system configuration parameters in eDirectory simplifies system administration and allows NetMail to leverage the strengths of eDirectory. For information on configuring eDirectory to maximize messaging system performance, see Understanding How NetMail and eDirectory Work Together.
The following sections discuss the eDirectory objects that make up the NetMail messaging system.
During your initial NetMail installation, the installation program extends the Novell eDirectory schema and creates the Internet Services container object at the root of your Directory tree. Because it is part of NetMail, the Internet Services container differs from other eDirectory Container objects. Only one Internet Services container can exist per tree and, as the messaging system container, it only contains NetMail component objects.
If the Internet Services container is deleted, it can only be re-created by running NIMSExt. For more information on the NIMSExt utility, see NIMSExt.
For information on the Internet Services configuration options, see Internet Services Container.
A messaging server is any server on the network that hosts one or more NetMail agents. In the eDirectory tree, the Messaging Server object represents the physical server where the NetMail software is installed.
The Messaging Server object is represented as a container with server attributes; it contains one or more agent objects and it defines the messaging server properties. For specific information on creating and configuring the messaging server, see Messaging Server .
Because the Messaging Server object is NetMail specific, it does not replace the NCP Server object. Instead, each Messaging Server object is associated with an NCP Server object in the tree.
Because of the NetMail system's building block architecture, you can implement your entire messaging system on a single server or distribute NetMail services across multiple messaging servers. In environments with multiple messaging servers, you can configure the servers to work together as a single, integrated messaging system (distributed environment), or let them operate as independent subsystems (standalone environment).
NOTE: For help in determining if a standalone or distributed messaging server would best suit your messaging environment, see Selecting Your NetMail System Configuration.
In a distributed messaging system, multiple messaging servers work together as a single, integrated system. Distributed messaging servers are able to work together because they look for other Messaging Server objects in the Internet Services container. If a Messaging Server object or an alias of that object exists in Internet Services, other distributed messaging servers can find and interact with it. By default, messaging servers are created in distributed mode.
Distributed messaging servers are most often used in larger messaging systems such as ISP, ASP, and multi-LAN environments. Because of message traffic volume, performance requirements, or the local distribution of the network, these organizations typically require multiple messaging servers to provide the load balancing, fault tolerance, and speed needed to service their customers.
The following examples illustrate ways to use distributed messaging servers to achieve specific system goals:
For specific agent distribution strategies, see Creating and Configuring NetMail Agents .
A standalone messaging server does not interact with other messaging servers. Instead, it acts as an independent messaging system, exclusively providing all NetMail services to the users within its assigned contexts.
By default, messaging servers are created in distributed mode. To configure a standalone messaging server, you must disable Distributed Processing in the messaging server's Properties menu. This prevents the messaging server from looking for other Messaging Server objects in the Internet Services container.
The two most common situations to use standalone messaging servers are:
Parent objects enable administrators to collectively manage agent services and user settings for specific sets of users. This functionality enables the administrator to subdivide a single messaging system into configuration subunits. For example, by creating separate Parent objects for each domain, administrators can manage every domain as if it were a separate messaging system.
The Parent object is a collective management tool that offers other significant advantages. The configuration options in the Parent object allow administrators to selectively grant access to messaging services. This means that although an agent is running on the messaging server, not everyone can access the agent's services. Instead, the administrator can enable or disable different agent services for each Parent object. For example, in an ISP environment, the system administrator could use Parent objects to give one Hosting Domain access to POP and another access to IMAP. This allows the ISP to bill for individual services. For more information on using Parent objects to manage messaging services, see Feature Management.
You can also use Parent objects to distribute administrative tasks. You can give selected users rights to create, delete, modify, or import user accounts in specific Internet domains. For example, in a corporate environment, the system administrator could use Parent objects to give administrative assistants rights to create their department's user accounts. Because all administrative functions are performed in WebAccess, the operations are familiar, intuitive, and user-friendly. Moreover, users do not need to know anything about eDirectory. For further information, see Task-Oriented Management.
Agents running on both distributed and standalone messaging servers dynamically look up the user's Parent object in the tree to determine what rights the user has to the service.
For more information on creating and configuring Parent objects, see Leveraging Parent Objects.
The Parent container is created in Internet Services during installation. This container is the centralized location for Parent objects. NetMail agents reference the Parent container when looking up user configuration information.
IMPORTANT: Every Parent object must be represented in the Parent container for NetMail Agents to find it. If a Parent object is created elsewhere in the tree, it must be represented by an Alias object in the Parent container. (You cannot create Alias objects in WebAdmin; therefore, you must use another administrative tool, such as iManager, to create the Alias object in the Parent container.)
If the Parent container is deleted, it can only be re-created by re-running NIMSExt. For more information on the NIMSExt utility, see NIMSExt.
Resource objects represent shared resources such as conference rooms, training facilities, equipment, and so forth. By creating the Resource object in a supported NMAP context, the resource automatically has its own mailbox and calendar.
To schedule a resource, users simply create an appointment and include the resource in the appointment's list of scheduled attendees. Users can also busy search Resource objects' calendars. The Resource object automatically accepts appointments that do not conflict with its calendar, or declines appointments that do.
To allow a user, such as an administrative assistant, to manage the resource's mailbox and calendar, you can assign the user as a Resource Manager. This gives the user full proxy rights to the resource's mailbox.
For more information on Resource objects, see Resource Objects.
The Modular Web Agent provides two template-based, mail client interfaces: WebAccess (Webacc.ctp) and Webmail (WebMail.ctp).
The WebAccess interface provides standard mail client functionality, calendaring, scheduling, tasks, notes, shared folders, busy search and user self-administration features like changing passwords and configuring vacation messages. Administrators can also use the WebAccess interface to give selected users access to administrative functions such as adding, modifying, and deleting user accounts.
Webmail is patterned after the NIMSTM 2.5 mail client interface. Like WebAccess, it provides standard mail client functionality, calendaring, scheduling, tasks, notes, shared folders, busy search, and user self-administration tasks like changing passwords and configuring vacation messages. However, WebMail does not provide administrative functions like adding, modifying, and deleting user accounts.
Webacc.ctp and WebMail.ctp each contain everything needed to present their respective client interfaces; the HTML codes, program strings, language files, graphics, etc. are all compiled in the template files. The WebAccess and WebMail objects are automatically created in the Templates container under Internet Services during installation. When the Modular Web Agent initializes on the messaging server, it references the template objects in the tree and loads the associated template files into memory.
For more information on creating and configuring Template objects, see Templates.
The Templates container is created in Internet Services during installation. This container is the centralized location for template objects. The Modular Web Agent references the Templates container when scanning for available templates.
IMPORTANT: Every Template object must be represented in the Templates container for the Modular Web Agent to find it. If a Template object is created elsewhere in the tree, it must be represented by an Alias object in the Templates container. (You cannot create Alias objects in WebAdmin; therefore, you must use another administrative tool, such as iManager, to create the Alias object in the Template container.)
If the Templates container is deleted, it can only be re-created by re-running NIMSExt. For more information on the NIMSExt utility, see NIMSExt.
The NetMail List Agent allows administrators to create and maintain mailing lists. Mailing lists are essentially public communication forums. They are used to broadcast information via e-mail. NetMail provides two types of mailing lists: list server Mailing Lists and NDS® Mailing Lists.
For more information on creating and configuring list objects, see Managing Mailing Lists.
A list server mailing list is a compilation of user e-mail addresses. When a message is sent to the mailing list, the message is automatically forwarded to every user in the mailing list.
Typically, users subscribe to list server mailing lists. To subscribe, users send a message to the list server's e-mail address with the word "subscribe" in the body of the message.
For information on Mailing List configuration options, see Mailing Lists.
List User objects represent the members of a Mailing List. When users subscribe to a mailing list, a List User is added to the respective Mailing List object. Administrators can also add mailing list members by creating List User objects within the Mailing List object.
For information on List User object configuration options, see List User Objects.
NDS mailing lists allow you to broadcast messages to eDirectory users. Unlike list server mailing lists, NDS mailing lists are comprised of eDirectory objects rather than user e-mail addresses. Selected eDirectory objects can include Container objects, Groups, organizational roles, aliases, and individual User objects.
NOTE: If a Container object is selected, messages are forwarded to the users within the designated Container object.
For information on NDS Mailing List configuration options, see NDS Mailing Lists.
The Mailing Lists container is created in Internet Services during installation. This container holds all of the messaging system's available Mailing List objects. The List Agent references the Mailing Lists container when scanning the message queue for messages addressed to mailing lists.
IMPORTANT: Every Mailing List object must be represented in the Mailing Lists container for the List Agent to find it. If a Mailing List object is created elsewhere in the tree, it must be represented by an Alias object in the Mailing Lists container. (You cannot create Alias objects in WebAdmin; therefore, you must use another administrative tool, such as iManager, to create the Alias object in the Mailing Lists container.)
If the Mailing Lists container is deleted, it can only be re-created by re-running NIMSExt. For more information on the NIMSExt utility, see NIMSExt.
The WebAdmin Agent is represented in eDirectory by the Web Administration Server object. The Web Administration Server object is automatically created in the same context as the NCP Server object when the WebAdmin Agent is installed to the server.
For information on the WebAdmin object's configuration options, see Configuring WebAdmin.
When NetMail is installed, existing Directory objects, such as Container, User, and even Server objects, take on additional attributes. These attributes allow you to manage specific messaging system services. For complete explanations of the properties added to Container, User, and Server objects, see eDirectory Object Configuration Options.
During installation, NetMail extends the definition of the NCP Server object to include the following properties:
Internet Mail identifies the Messaging Server object associated with the current NCP Server object.
Syslog is provided for backward compatibility only. In this page, administrators can define server-specific syslog files for NetMail 3.1 and earlier systems.
IMPORTANT: In NetMail 3.5, all system logging is handled through Novell Nsure Audit.
Nsure Audit has separate menus for NetWare, Filesystem, and eDirectory events. These properties manage the log settings for eDirectory, NetWare, traditional file system, and NSS events. Each menu lists the events that fall in its respective category. To configure the logging server to log a particular type of event, simply mark the event's check box, then click Apply. After you click Apply, the logging server automatically begins logging the marked events. For more information on configuring the NCP Server object's Nsure Audit attributes, see "Logging eDirectory, NetWare, and File System Events" in the Nsure Audit 1.0.1 Administration Guide.
For information on the NCP Server object's NetMail and Nsure Audit configuration options, see Server Objects.
NetMail properties for Container objects include the option to define a custom message store for users within the current container and a container-specific domain name.
The container-specific message store is the volume and directory where the mailboxes for users in the current container are located. This does not affect the general message queue and SCMS directories, which are always located in the default message store volume and directory.
If configured, container domains appear in the From field of user messages and are referenced by the Address Book Agent in returning users' address book information.
IMPORTANT: Container domains do not allow you to have non-unique user IDs in different containers.
For information on the Container object's NetMail configuration options, see Container Objects.
The NetMail attributes for User objects replicate many of the user configuration options available in the Modular Web client, including privacy level, forward and autoreply messages, and proxy configuration.
Providing the user configuration options in both the User object and Modular Web client gives administrators the option of centrally managing these options through the User object or allowing users to self-manage these options through the Modular Web client.
The User object also replicates many of the configuration options available in Parent objects.This duplication lets the administrator configure general settings in the Parent object, but create "exceptions to the rule" in individual User objects. For example, in the Parent object the administrator can set a mailbox quota for users in an Internet domain. However, at the User object level, the administrator can allocate a larger mailbox quota for the domain's Webmaster.
For information on User object's NetMail configuration options, see User Objects.
NetMail agents are a series of executables that perform specific product functions. These agents have plug-and-play versatility; that is, they can be combined in a variety of configurations and still maintain the functionality of a single, integrated messaging system. This building block architecture allows you to easily distribute NetMail across multiple servers. Depending on agent usage and system resources, each agent can run by itself or in conjunction with other agents on a messaging server.
The following table lists all the NetMail agents and summarizes their contributions to your NetMail system. For a complete explanation of each agent's configuration options, see NetMail Configuration.
| Agent | Icon | Agent Function |
|---|---|---|
Address Book Agent |
|
The Address Book Agent provides read-only LDAP3 access to eDirectory. Using this agent, any LDAP-compliant application (such as e-mail or address book clients) can access address book information from eDirectory. Information returned about each user depends on the user's privacy level. NOTE: Do not confuse the Address Book Agent with the Modular Web Agent's address book feature. The Modular Web Agent address book is a user feature that can look up information in virtually any LDAP-compliant database. The Address Book Agent enables address book clients (such as the Modular Web Agent address book) to query eDirectory for address book information. For more information, see Address Book Agent. |
Alias Agent |
|
The Alias Agent enables your NetMail system to recognize user aliases. You can also use the Alias Agent to automatically populate the User object's Internet E-mail Address property. You can define aliases manually or automatically in the Alias Agent. The automatic aliasing feature pulls information directly from eDirectory to generate aliases for eDirectory User objects. You can automatically generate aliases in the following formats:
Manually defined aliases can correspond to any Internet mail address such as webmaster@company.com. The aliases created via the Alias Agent are not defined as Alias objects in eDirectory; rather, they are maintained by the Alias Agent and are specific to the NetMail messaging system. Existing eDirectory Alias objects are recognized by NetMail, but they function independently of the Alias Agent. Messages addressed to Alias objects are automatically delivered to the associated user's mailbox by the NMAP Agent. For more information, see Managing User Aliases. |
AntiSpam Agent |
|
The AntiSpam Agent automatically allows the postmaster or NetMail administrator to build a blackout list of undesirable e-mail domains and addresses. Messages sent from domains and e-mail addresses contained in the blackout list are not accepted by your NetMail system. For more information, see AntiSpam Agent. |
AntiVirus Agent |
|
The NetMail AntiVirus Agent integrates with Command* Antivirus, Computer Associates* InnoculateIT*, McAfee* NetShield*, and Symantec* AntiVirus Scan Engine to provide virus scanning on messages handled by NetMail. If a message contains a virus, the AntiVirus Agent immediately deletes it from the message queue. You can configure the agent to return the message to the sender with a notice indicating what virus the message contained. It can also send a virus alert to the message recipients indicating who tried to send the message and what virus the message contained. Within the messaging system, you can enable virus scanning for all users or limit it to a group of users. Limiting virus scanning to specific users is most applicable to ISP environments where users subscribe to this service. Virus scanning is enabled in the Parent or User object. IMPORTANT: You must install one of these vendors' products before you can use the NetMail AntiVirus Agent. For more information, see Providing AntiVirus Protection. |
AutoReply Agent |
|
The AutoReply Agent allows users create custom messages that are automatically sent in response to incoming mail. For example, when users go on vacation, they can create a message that lets others know they are unavailable. The AutoReply Agent also enables users to forward their messages to another e-mail address. Users can specify if they want to retain a copy of the message in their NetMail mailbox or simply redirect the message to the designated address. In addition to forwarding messages to another e-mail address, the AutoReply Agent can forward SMS messages to cellular phones and pages. Although it does not configure SMS messages, the AutoReply Agent can recognize a message's format and forward it to the user's designated cellular phone or pager number. The AutoReply Agent is not e-mail client specific. Although users must configure mail forwarding and autoreply messages in the Modular Web client, the agent functions independently of any e-mail client. This is because users' forward and autoreply information is stored in their User objects. Therefore, NetMail can handle forwarding and autoreply messages for users of POP3, IMAP4, and Modular Web clients. For more information, see AutoReply Agent. |
Calendar Agent |
|
The Calendar Agent provides automatic status-tracking information for scheduled appointments, tasks, and notes. When a user schedules a calendar event, the Calendar Agent processes all Accept, Delegate, and Decline responses and automatically updates the event's status information in the event organizer's calendar. Only the user who schedules the event can view who has accepted, delegated, or declined a calendar event. Attendees see only their own status; every other attendee is viewed as pending. This design avoids the spikes in network traffic that would occur if every attendee updated every other attendee's status. If you choose not to run the Calendar Agent, users receive iCal status messages in their Inboxes. Because the status information is in iCal format, the event organizer might not be able to discern whether a recipient has accepted, delegated, or declined the appointment. If you are using the Modular Web client, you must run the Calendar Agent to provide automatic status tracking for scheduled appointments. For more information, see Calendar Agent. |
CAP Agent |
|
The CAP Agent allows the Novell GroupWise v 6.5 Collaboration Client for Novell NterpriseTM Linux Services v1 to busy search NetMail calendars. The CAP Agent is used only by the GroupWise client. If you are not using the GroupWise client, you do not need to load the CAP Agent on your messaging server. For more information, see CAP Agent. |
Connection Manager |
|
The Connection Manager Agent keeps track of authenticated users. When a user logs in via POP3 or IMAP4, the POP or IMAP Agent gets the client's IP address and sends it to the Connection Manager Agent. Connection Manager then keeps track of the IP address for a designated time period. (The default is 15 minutes.) Any agent can query Connection Manager for authenticated IP addresses. In NetMail, this service is utilized by the SMTP Agent for SMTP-after-POP. SMTP-after-POP is a spam-protection feature that prevents unauthorized users from relaying mail through your messaging system. See Preventing Others From Using Your System to Relay Spam for more information. The Connection Manager Agent listens to other agents on UDP port 689. Ensure that it is always protected by a firewall. For more information, see Connection Manager. |
Finger Agent |
|
The Finger Agent allows NIMS users to provide customized responses to finger requests from other users. This agent is provided only for backward compatibility and is no longer supported by Novell. |
IMAP Agent |
|
The IMAP Agent enables IMAP4 clients to download mail from the messaging system. In addition to the basic NetMail memory requirements, the IMAP Agent requires approximately 300 KB per expected simultaneous connection to your NetMail system. For users to access their mailboxes, your messaging system must include at least one POP, IMAP, or Modular Web Agent. For more information, see IMAP Agent. |
List Agent |
|
The List Agent enables your NetMail system to function as a list server for two-way, fully interactive discussions to one-way lists that deliver announcements, newsletters, and advertising. The list server works in conjunction with the NDS Mailing List and Mailing List objects. NDS-based mailing lists are built from Container, Group, Role, or User objects while general mailing lists are Internet-based and require the full e-mail address of each subscriber. When you send messages to a mailing list, undeliverable status information is not returned if one of the messages is rejected. For more information, see List Agent. For complete information on creating and managing mailing lists, see Managing Mailing Lists. |
Modular Web Agent |
|
The Modular Web Agent provides the template interfaces for the NetMail mail client. There are two available templates: WebAccess and Webmail. Using either template, users can send and receive mail, manage folders, and set mail preferences from any standard Internet browser. The Modular Web Agent also includes several modules that enable various client functions.
In addition to the basic NetMail memory requirements, the Modular Web Agent requires approximately 300 KB per expected simultaneous connection to your NetMail system. For users to access their mailboxes, your messaging system must include at least one POP, IMAP, or Modular Web Agent. For more information, see Modular Web Agent and Modular Web Agent Modules. |
NMAP Agent |
|
The NMAP Agent is responsible for managing message processing and delivery. It coordinates everything that happens from the time a message enters the message queue to when it is delivered to the user's mailbox or passed off for delivery via the Internet. It is the only agent that has direct access to the message store. Consequently, every messaging system requires at least one NMAP Agent and every user within the messaging system must be included in one of the NMAP Agent's contexts. The NMAP Agent's three primary functions are:
For more information, see NMAP Agent. |
Pluspack Agent |
|
The Pluspack Agent was previously available but unsupported. NetMail 3.5 integrates the Pluspack Agent in the standard NetMail feature set. The Pluspack Agent provides the following options:
For more information, see Pluspack Agent. |
POP Agent |
|
The POP Agent enables POP3 mail clients to download mail from the messaging system. In addition to the basic NetMail memory requirements, the POP Agent requires approximately 200 KB per expected simultaneous connection to your NetMail system. For users to access their mailboxes, your messaging system must include at least one POP, IMAP, or Modular Web Agent. For more information, see POP Agent. |
Proxy Agent |
|
The Proxy Agent allows users to manage several e-mail accounts from a central mailbox. Users can retrieve messages from up to three POP3 or IMAP4 e-mail accounts on other messaging systems. All messages retrieved from these accounts are stored in the user's NetMail mailbox as if it were the original destination. NOTE: The Proxy Agent cannot retrieve messages from mail systems that do not provide POP3 or IMAP4 access to their mailboxes. Additionally, some e-mail providers allow access to your mailbox only if you log in within a specified IP address range that belongs to the service. These providers assign an IP address upon login. In these cases, Proxy does not work even if it is a POP3 or IMAP e-mail service. Depending on the user settings, you can leave a copy of retrieved messages in the original mailbox or delete the messages from the host server. All proxy information is stored in the User object. For more information, see Proxy Agent. |
Rule Agent |
|
The Rule Agent executes rules defined in the Modular Web client. The Rule Agent is not e-mail client specific. Although users must configure rules in the Modular Web client, the agent functions independently of any e-mail client because users' rules are stored in their User object. Therefore, NetMail executes the configured rules whether the users open their messages in a POP3, IMAP4, or Modular Web client. For more information, see Rule Agent. |
SMTP Agent |
|
The SMTP Agent is the gateway between the Internet and your messaging system. Its primary function is to transfer messages to and from the Internet. For users to send local messages from POP or IMAP clients or to send messages over the Internet, you must run at least one SMTP Agent on the messaging server. Because the SMTP Agent is the point of entry for all messages received over the Internet, it determines which domains that the messaging system recognizes. Every domain that resolves to the SMTP server's IP address must be included in the SMTP Agent's domain list or messages are bounced back to their senders. The SMTP Agent also provides most of the spam-protection features for NetMail. Options like reverse DNS lookups, Realtime Blackhole List (RBL) lookups, and host blocking by IP address protect your system from incoming spam, while features like ESMTP authentication, SMTP-after-POP, and restrictions on remote sending by IP address protect your system from spammers using your system to relay spam. Additional SMTP Agent options include the following:
For more information, see SMTP Agent. |
WebAdmin |
|
WebAdmin is a browser-based, platform-independent, system management tool. Administrators access WebAdmin through a browser by typing the URL or host name of the messaging server with WebAdmin's port assignment. For example:
NOTE: On standard versions of NetMail, WebAdmin uses port 89 for HTTP and port 449 for HTTPS connections. On Novell Nterprise Linux Services, WebAdmin uses port 8018 for HTTP and port 8020 for HTTPS connections. For more information, see WebAdmin. |
