EP1208477A1

EP1208477A1 - Methods and apparatus for delegating administrative capabilities to domains served by mail providers

Info

Publication number: EP1208477A1
Application number: EP01918415A
Authority: EP
Inventors: William H. Abbott; Mayank Choudhary; Anil K. Srivastava; Timothy C. Misner; Daryl A. Huff
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-03-07
Filing date: 2001-03-06
Publication date: 2002-05-29
Also published as: WO2001067305A1; EP1208477A4; AU4549501A

Abstract

Broadly speaking, an Internet standards-based messaging system (600) having a mail server (602) capable of offering email services to multiple organizations (604) each of which having their own virtual domain. In addition, the messaging system (600) is capable of providing administrative capabilities that can be exercised locally be organizations that are served by the mail server (602). Advantageously, a remote user located in an organization served by the mail server can access the directory services to perform a variety of administrative tasks remotely. Furthermore, administrative tasks such as adding and deleting users can be done automatically by a local administrator without requiring specific knowledge about the implementation details of the mail server and directory services.

Description

METHODS AND APPARATUS FOR DELEGATING ADMINISTRATIVE CAPABILITIES TO DOMAINS SERVED BY MAIL PROVIDERS

INVENTORS:

William Abbot Mayank Choudary Anil Shrivastava Timothy Misner Daryl Huff

FIELD OF THE INVENTION

The present invention relates in general to client/server data communication systems and, more particularly, to a mail server included in an electronic mail system for use within a client/server data processing system. More particularly still, the present invention is directed towards a method and apparatus for delegating administrative tasks to domains served by a service provider in an email system.

BACKGROUND OF THE INVENTION

Computer systems are well known in the art and have become a business staple and are also found in many homes. One feature available to the business world is that of using electronic mailing (email) to send and receive messages and other information to and from one another in a business setting. Similarly, home computers, such as desk tops or laptops, and other information devices, such as personal digital assistants

(PDAs), allow telecommuting such that a user can connect to the user's work server and down load and upload messages.

The email system allows clients of a network system, which is maintained by a server system, to send messages or data from one user to another. In order to minimize disk space and requirements as well as to maximize functionality and consistency of the electronic mailing engine used in the network system, the engine is typically located on the server and is merely accessed by a client in order to send messages or retrieve messages to or from another user or client on the server system. In this way, the client system typically allows the user to perform such operations as composing, updating, and sending messages while the server in such a system provides, in part, a server based message repository as well as providing message transmission and reception functions for the user at the client level.

A traditional email system 100, configured to operate in what is referred to as a consumer host mode, is illustrated in Fig. 1. The email system 100 includes a number of consumers and/or businesses 102-1 ("abc.com") through 102-n ("xyz.gov") each of which is coupled to a service provider (SP) 104 ("isp.net"). Traditionally, the service provider (SP) 104 provides the various consumers and/or businesses 102 with just an unprotected IP router. The consumers and/or businesses 102 also operate and maintain their own application servers, including the email server, DNS server, and (if needed) LDAP server (not shown). For their own protection, each of the consumers and/or businesses 102 must operate through a firewall that filters out undesirable packets and insulates the organization's internal network from the Internet. Notice that for many organizations, especially small ones, the email server may actually be the firewall system.

In the email system 100, those consumers and/or businesses 102-1 through 102-n who wish to read their mail must be connected to a service provider (SP) email server 106. The SP 106 also operates an email mailbox 108, and a DNS server 110 that provides the following services, a primary master server for the SP's own domain (ISP.net), to designate as the root server for all consumers and/or businesses, act as a primary master server for consumers and/or businesses who do not wish to maintain their own public DNS server, and as a secondary server for consumers and/or businesses who prefer to maintain their own public server.

As part of the services provided by the SP 106, an SMTP relay host 112 that is managed by the SP offers offer a number of value added services, for which the SP may charge additional fees. In some cases, the relay host can be configured to allow the relay host to accept and hold the consumer's email when their mail server is down. However, unfortunately, the relay host imposes a significant management burden on the SP since in some cases, consumer email may live on this server for an indefinite time raising issues of backup and failure recovery. If one of the consumer servers fails because of being swamped, for example, then the consumer's email may roll over to the SP's relay host. Because of this, most SPs do not offer a relay host for those consumers and/or businesses that are hosting their own email server. The SP also provides a directory service in the form of the LDAP Directory server that is located at the consumer's site, which can be operated by the consumer. In this way, most organizations do not expose their LDAP servers to the public network for security reasons.

In the example shown in Fig. 1, a mail user in ABC, Inc. (which lawfully owns its DNS domain name abc.com, but relies on the ISP isp.net to host its email) desiring to send and receive mail uses the domain name username@,abc.com even though his mailserver is really mailhost.isp.net. It also means that any user in the abc.com domain, connects to a mailhost in the domain abc.com - for example mail.abc.com - to access his/her mail.

Since the email system 100 requires a separate mail server to be supported by the SP 106 for each of the domains abc.com through xyz.gov, although well understood and easy to manage, the email system 100 is not cost effective for small domains. In addition, as the number of domains increases, the management of the individual services becomes increasingly unwieldy. Internet service providers (ISPs) have a growing interest in hosting email services for always larger and more numerous organizations. Many businesses see the ability to farm out email services as a very attractive cost- saving idea. It is therefore desirable that an email service provider be able to offer email services to multiple organizations each of which has their own virtual domain and to support the ability to define such domains in the directory and host them on a shared mail server. Thus, an email architecture that can support a single mail server which, in turn, can support many different domains associated with consumers and/or businesses is desirable. Among other things, this email architecture would be useful for a mail service provider such as ISP 104.

In addition, it would be useful to provide some administrative capabilities to the consumers supported by the mail server. To elaborate, it would be cumbersome and inefficient for service providers to perform all the mmiscule administrative tasks such as adding and deleting individual users to a domain. Furthermore, the ability to perform administrative tasks, provides consumers more flexibility in configuration of the consumer's mail system.

In view of foregoing, there is a need to delegate administrative tasks to the consumers supported by electronic mail service providers.

SUMMARY OF THE INVENTION

According to the present invention, a standards-based messaging system is disclosed. The disclosed messaging system includes a mail server capable of offering email services to multiple organizations each of which having their own virtual domain. In addition, the messaging system is capable of providing administrative capabilities that can be exercised locally by organizations that are served by the mail server. In accordance with one aspect of this invention, a messaging system including an administrative system is disclosed. In one embodiment, the administrative system provides an interface to allow access to the directory services of a mail server. Advantageously, a remote user located in an organization served by the mail server, can access the directory services to perform a variety of administrative tasks remotely. Furthermore, administrative tasks such as adding and deleting users can be done automatically by a local administrator without requiring specific knowledge about the implementation details of the mail server and directory services. As an electronic mail messaging system having a mail server arranged to provide electronic mail services to at least one email mailbox, one embodiment of the invention includes a mail administrative delegator coupled to the mail server configured to delegate an administrative function associated with the electronic mail services provided by the mail server to the at least one entity. As a method for remotely performing administrative tasks associated with electronic mail services provided by a mail server operating to provide mail services to at least one entity, one embodiment of the invention includes: initiating a remote connection; establishing a remote connection; initiating an administrative task; calling a client function; calling one or more client procedure to perform the client function; and performing the administrative task. As a computer readable media including computer program code, one embodiment of the invention includes: computer program code for initiating a remote connection; computer program code for establishing a remote connection; computer program code for imtiating an administrative task; computer program code for calling a client function; computer program code for calling one or more client procedure to perform the client function; and computer program code for performing the administrative task.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: Fig. 1 illustrates a conventional customer hosted type e-mail system.

Fig. 2 shows an Internet email system in accordance with an embodiment of the invention.

Fig. 3 shows an exemplary message store in accordance with an embodiment of the invention. Fig. 4 shows a flowchart detailing a process whereby a virtual domain is defined in accordance with an embodiment of the invention.

Fig. 5 illustrates an administrative system implemented as a client-server model, in accordance with another embodiment of the present invention.

Fig. 6 illustrates a method of performing an administrative task by a user located in a remote location, in accordance with yet another embodiment of the present invention.

Fig. 7 illustrates a typical general-purpose computer system suitable for implementing the present invention.

Fig. 8 illustrates a typical general-purpose computer system suitable for implementing the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to a preferred embodiment of the invention. An example of the preferred embodiment is illustrated in the accompanying drawings. While the invention will be described in conjunction with a preferred embodiment, it will be understood that it is not intended to limit the invention to one preferred embodiment. To the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.

The Internet has effectively lowered the cost of electronic communication. As the number of people and organizations connected to the Internet has grown, the Internet has evolved into a new channel for communication. To facilitate Internet services, Internet messaging clients and easy-to-use web browsers have provided cost-effective way of publishing and sharing information with employees inside the enterprise as well as customers, suppliers, and partners outside. Since messaging services has become crucial to enterprise infrastructure in the 1990s, organizations are seeking messaging solutions that provide a lower cost of ownership while increasing the effectiveness and reliability of their communications network. Specifically, they are evaluating the benefits of Internet standards-based messaging systems.

Broadly speaking, the invention describes an Internet standards-based messaging system having a mail server capable of offering email services to multiple organizations each of which has their own virtual domain. The invention is also able to define such virtual domains in the directory and host them on a shared mail server.

In addition, the messaging system is capable of providing administrative capabilities that can be exercised locally be organizations that are served by the mail server. In accordance with one aspect of this invention, a messaging system including an administrative system is disclosed. In one embodiment, the administrative system provides an interface to allow access to the directory services of a mail server.

Advantageously, a remote user located in an organization served by the mail server can access the directory services to perform a variety of administrative tasks remotely. Furthermore, administrative tasks such as adding and deleting users can be done automatically by a local administrator without requiring specific knowledge about the implementation details of the mail server and directory services.

The invention will now be described in terms of an internet mail server resident on a server computer coupled to a large network of mailboxes typical of a large corporate intranet system as well as a single user coupled to a large interconnected computer network such as the Internet. It should be noted, however, that the inventive mail server is well suited to any application requiring highly reliable, scalable, and efficient information transport over a large number of computers.

Referring now to Fig. 2, an Internet email system 300 in accordance with an embodiment of the invention includes an Internet mail server 301 coupled to a user mailbox 303. In the described embodiment, the mail server 301 is a general-purpose, " store-and-forward" system for distributing computer-based mail. It should be noted that the term " store-and-forward" means that the mail server 301 automatically handles the receiving of mail messages necessitated when network links (such as those links 306 to the Internet) or other services are temporarily unavailable. In contrast to mail user agents (MUAs) that are used to create and read electronic mail messages, a transfer unit 302 included in the mail server 301 is responsible for directing messages to the appropriate network transport and ensuring reliable delivery over that transport. In a preferred embodiment, the mail server 301 includes a message store unit 304 coupled to the transfer unit 302 that is used to store messages for later transmission to the user mailbox 303.

As shown in Fig. 3, in one implementation, the message store 304 in the mail server 301 is a dedicated data store for the delivery, retrieval, and manipulation of Internet mail messages. In a preferred embodiment, the message store works with the IMAP4 and POP3 to provide flexible and easy access to messaging. It saves any message that conforms to RFC 822 specifications, and recognizes the Multipurpose Internet Mail Extensions (MIME) content format. In the described embodiment, the message store 304 is organized as a set of folders and user mailboxes. The mailbox 401 is a container for messages where each user has an inbox 402 where new mail arrives, and can have one or more folders 404 where mail can be stored. Folders 404 may contain other folders or mailboxes and may be arranged in a hierarchical tree. Mailboxes owned by an individual user are private folders 406. In addition to a user owning a folder or a mailbox, a common user or group can share the ownership of a folder or mailbox as a shared folder 408. A shared folder is similar to an email group, but instead of messages going into each member of the email group's inbox, messages addressed to the shared folder 408 go into a private folder associated with each user. It should be noted that in a preferred embodiment, the message store 304 maintains only one copy of each message. However, in those cases where the message store 304 receives a message addressed to multiple users or a group (based upon an associated distribution list), it adds a reference to the message in each user's inbox rather than having a copy of the message in each user's inbox, thereby saving disk space. In addition to the reference, the individual message's status (new, unread, replied to, deleted, and the like) is maintained per mailbox.

In the described embodiment, access to the message store 304 is multithreaded thereby allowing a single process to manage a large number of connections since each connection is handled by a thread. In this way, multithreaded access maximizes both performance and scalability by mimmizing the system resources required for the management of each connection.

Referring back to Fig. 2, the delivery and routing of messages by the transfer unit 302 is based on a routing table 310 that in turn is derived from the user and group (distribution list) entries stored in a directory service unit 312. In a preferred embodiment, the directory service unit 312 is the central repository for meta- information: user profiles, distribution lists, and other system resources based upon, in some embodiments, a dedicated Lightweight Directory Access Protocol (LDAP) directory service. This directory supports the storage of information according to a directory information tree (DIT) which is a hierarchical structure that resembles a tree with one major branch at the top and many branches and sub-branches below. The arrangement of the tree is flexible, allowing administrators to decided how to best deploy the service for their organization. For some, it may be best to arrange the tree according the actual business organizational structure or geographic structure. For others, however, a one-to-one mapping to DNS layers may be best.

The DIT also provides the flexibility to support a wide range of administration scenarios, and can be administered in either a centralized or distributed manner. Centralized administration can be implemented where one authority manages the entire DIT. This type of administration is usually used in scenarios where the entire DIT resides on one mail server.

In order to properly route a message, the transfer unit 302 must access the directory information associated with each message that it processes. However, in a preferred embodiment, rather than querying the directory service 312 directly each time it processes a message, the transfer unit 302 caches the directory information in a directory cache 314. When the transfer unit processes a particular message, it accesses the appropriate directory information in the cache 314. When required, the transfer unit 302 uses the directory information in the cache 314 to update the routing table 312.

Since a directory query for each recipient of each message is time-consuming and puts a large load on the mail server 301, by implementing the localized directory cache 314, performance of the email server 301 is improved, hi addition, since the information stored in the directory service unit 310 is not always in the format required by the transfer unit 302, when creating the cache, the transfer unit reformats the directory information as required. It should be noted that in most embodiments, a the transfer unit 302 can be configured to adhere to various mail delivery options which specify one or more delivery options for inbound email to a designated recipient. While inbound messages can be delivered into multiple message stores, message access servers (MAS) can read messages from only a designated one of them. The transfer unit 302 uses these attributes to determine the targets of message delivery for all messages submitted to a particular distribution list. Such attributes can include, but are not limited to: "autoreply", "program" where mail is delivered to a program, "forward" where mail is forwarded to another mailbox(es), "file" where the incoming message file is appended to another file, and "shared" where mail is delivered to a shared mailbox (this is typically used to set up a shared mailbox for a distribution list).

In the context of electronic mail, protocols are generally a high-level (not necessarily network specific) language spoken between two mailers. Transports are the low-level, network specific details used to implement a protocol on a given network. Thus email messages can come in to the transfer unit 302 by any one of a variety of transports and protocols—submitted directly by a local user, via TCP/IP as an SMTP message from an Internet system, by using a dial-up modem using the PhoneNet protocol, DECnet as a MAIL-11 message, DECnet as an SMTP message, UUCP, an X.400 transport, SNA, and so on. The transfer unit 302 then routes the message out using a transport and protocol appropriate for the message's destination address.

In the described embodiment, the transfer unit 302 uses what are referred to as channels to implement specific combinations of transports and protocols. Each different transport and protocol combination has an associated transfer unit channel. The transfer unit 302 postmaster initially configures the transfer unit 302 telling it what sorts of transports and protocols are in use at his site, and what sorts of destination addresses should be routed through which sorts of channels. For instance, at sites with an Internet connection, Internet addresses are normally routed through an SMTP over TCP/IP channel; but at sites with only a UUCP connection, Internet addresses would instead be routed through a UUCP channel. Once the transfer unit 302 is so configured using configuration data stored in a configuration table (not shown), the transfer unit 302 handles message routing and delivery automatically. In this way, ordinary users need never be aware of this underlying transport and routing; that is, they simply address and send their messages and the transfer unit 302 automatically routes and delivers them appropriately.

In most embodiments, the transfer unit 302 stores messages as text files. Messages with multiple parts (possibly containing different types of data) are represented as a series of text sections separated by special unique delimiter strings. In the described embodiment, the first few files in each email message are referred to as the message envelope that contains transport information. The message envelope is terminated by a line containing a boundary marker, or by a line containing two CTRL/A characters. The transfer unit 302 uses the contents of the envelope to make routing decisions. It does not use the content of the message. The content of the envelope is primarily defined by RFC 821. It includes the originator address, the recipient(s) address(es), and envelope ID.

The header lines of the message follow the envelope whose format is mandated by RFC 822. It should be noted that there may be any number of message header lines; the message header formed by this collection of header lines is terminated by a single blank line after which follows the message body. An Internet mail message starts with one or more headers. Each header is composed of a field name followed by a colon then a value which can be generated by, for example, the composer of a message or the mail client. A transfer unit can also add headers to a message. Each transfer unit that accepts a message adds a received header to that message. The last transfer unit to accept the message and to actually deliver the message to the message store adds a return-path header. The received and return-path headers provides information that enables you to trace the routing path taken by the message if a problem occurs. Submitted messages from the Internet or local clients go to the transfer unit 302 via SMTP (Simple Mail Transport Protocol). If the message address is within the server 302 domain, the transfer unit 302 delivers the message to the message store 304. If, however, the message is addressed to another domain, the transfer unit 302 relays the message to another transport agent on the Internet or Intranet.

In a preferred embodiment, messages to the local domain are stored in the message store 304 depending on how the system is configured. Once messages are delivered to the appropriate mailbox, they can be retrieved, searched for, and manipulated by IMAP4 or POP3-based mail clients. The transfer unit 302 uses the directory 312 that, in a preferred embodiment, is configured as an LDAP type directory, to retrieve local user and group address information. When the transfer unit 302 receives a message, it uses the directory information to determine where the message should be delivered. The message store uses the directory services to authenticate users logging into their mailboxes. The message store 304 also obtains information about user message quota limits and message store type (IMAP or POP). Outgoing client messages go to the SMTP channel in the LDAP. The transfer unit 302 sends the message to an Internet transfer or, if the address is local, to the message store 304. It should be noted that the LDAP directory 312 is the master repository of all the information related to hosted domains. That is, the message access server retrieves the necessary information to associate a client with a domain from the LDAP directory 312. Similarly, the transfer unit 302 retrieves hosted domain information from the LDAP directory 312 to perform proper routing and address rewriting.

Referring now to Fig. 4, showing a flowchart that details a process 500 for defining a virtual domain in accordance with an embodiment of the invention. The process 500 begins at 502 by defining a virtual domain node in the DIT. Once a the virtual domain node has been defined, corresponding routing table entries are defined at 504 and at 506, various virtual domain attributes are stored at the virtual domain node. It should be noted that the various virtual domain attributes include a list of services permitted the domain. Such services include IMAP, IMAPS, POP3, POP3S, and SMTP, which in some cases requires presentation of credentials. Other of the services includes identification of a domain administrator who is authorized to manage the particular virtual domain, which includes setting particular user-level attributes for particular users in the domain.

Fig. 5 illustrates an administrative system 602, in accordance with one embodiment of the present invention. A mail server 604 provides mail service to consumer,- consumer-, in domain, -domain-, respectively. Each of these domains is associated with a virtual domain in the mail server 604. Thus, the mail server 604 provides mail service to these domains. Each domain, such as a domain^ in turn may provide email services for several users (user_j-user_n).

In accordance with one embodiment of the present invention, a domain can be provided with the ability to perform local administrative functions. Administrative tasks such as adding and deleting users in a domain can be exercised by a local administrator such as local administrator 606 of domain_!. In one embodiment, administrative tasks are performed by sending requests to the administrative system 602. Upon reception of a request to perform an administrative task, the administrative system 602, in turn may contact the mail server 604 to perform the desired task. By way of example, the local administrator 606 can add a new user to domain_! by interacting with the administrative system 602. The administrative system 602 provides an interface that allows a local administrator to perform administrative tasks, in accordance with one embodiment of the present invention.

Advantageously, a local administrator need not have knowledge of implementation details of the mail server 604. In addition, the administrative system 602 in conjunction with the mail server 604 provide other services such as authentication and security, error information, session management, memory management, etc. In this way, some administrative tasks can be delegated to local entities such as consumers represented by the domains serviced by an e-mail service provider. This provides the consumers with the flexibility to configure and manage their own email systems, as well as providing email service providers with an efficient mechanism to serve their customers.

Referring now to Fig. 6 illustrating an administrative system 701, in accordance with an embodiment of the present invention. The administrative system 701 is implemented as a client-server model that includes an administer server 702 and an administrative client 704. A user such as the local administrator 606 of domini can use the administrative system 701 to perform administrative tasks. In the described embodiment, the administrative system 701 provides an interface to access the appropriate component of a service provider, e.g., a directory services 706 to perform administrative tasks related to users of the domaini. More particularly, a user accesses the directory services 706 through the administrative client 704.

In one embodiment, the administrative client 704 uses an Application Program Interface (API) 708 to access the administrative server 702. The API 708 can be implemented as a high-level set of administrative functions that insulate the client' s user from the low-level implementation details needed to access the directory services 706. Typically, several low-level operations are required to complete the desired API function.

In one particular embodiment, the administrative server 702 is implemented as a Remote Procedure Call (RPC) server that utilizes a set of high-level functions. By establishing a RPC client connection, the appropriate high-level RPC call can be made and performed by the administrative server 702. The administrative client 704 can be implemented as library of functions, for example, a set of standard library functions of high level programming language such as C or C++. In addition, the administrative client 704 can be accessed through the library functions. An application program can use the functions provided in the library to access the client 704.

As will be appreciated by those skilled in the art, an application program can provide a user with a Graphical User Interface (GUI) to the administrative system 710. In this way, a user such as the local administrator 606 can interact with the GUI through a console 710 located in domiani. By way of example, an HTML application can be made accessible by an internet browser. In this way, a local administrator is provided with an easy-to-use tool to perform administrative tasks. In one particular embodiment, a local administrator is provided with a GUI to perform a variety of tasks such creating and editing single users and distribution lists. In addition, a local user, in contrast to a local administrator may be provided the ability to modify his personal profile, e.g., changing password, mail-forwarding, vacation-rules, distribution list subscribers, etc. Fig. 7 illustrates a method 800 for performing an administrative task by a user located in a remote location, in accordance with one embodiment of the present invention. The method 800 can be used to allow a user such as a local administrator in a domain to perform a variety of administrative tasks. Initially, at operation 802, the user initiates a remote connection to the administrative system to access the directory services of a mail service provider. As noted by operation 804, typically, authentication is performed to validate a user and to determine the scope of privileges for the user. In one embodiment, a logical session is established between the user and the administrative system of an e-mail service provider. By way of example, to establish a session, a "login" function that accepts parameters such as a unique user id, password, etc. can be implemented, in accordance to a particular embodiment of the present invention. In addition, a data structure containing a "session handle" can be allocated and assigned for a logical session. The session handle data structure can be returned by the "login" function. As will be appreciated by those skilled in the art, the "session handle" can be used by a client to call various administrative functions during the logical session, hi addition, other information such as error messages can be provided during the logical session.

Next, in operation 806, the user initiates an administrative task. In one embodiment, several administrative functions are supplied to allow creating, deleting, modifying, and reading a user entry associated with an email account. Similarly, functions for creating, deleting, modifying, and reading a distribution list can be provided. Broadly speaking, a distribution list can be referred to as a list containing two or more users (email addresses). The distribution list can be used to send a message to all the users on the distribution list by specifying a single distribution list (address). In addition, functions for reading the virtual domain's attributes and search functions are provided, in accordance with a particular embodiment of the present invention. The search functions include functions for finding users and distribution lists, as well as determining membership of a user in a domain and distribution list.

To perform an administrative task initiated by user at the operation 806, the appropriate one or more administrative client functions are called, as noted by the operation 808. As noted above, the client functions can be provided in a library that is implemented in a programming language such as C, C++, etc. Next at operation 810, the appropriate one or more corresponding server administrative functions are invoked to perform the desired administrative task. The administrative task is performed at operation 812. Typically, performing a server function requires several low-level operations to access directory services of a mail server and to perform the desired administrative task. Upon successful completion of a task the user is provided by a verification. In case of a failure or error condition, the user can be provided by an error message or other information to indicate a problem. Finally, at operation 814, the user disconnects the remote connection to the administrative system. In one embodiment, the established logical session is disconnected by using a "logout" function. It should be noted that after a user establishes a connection, the user may continue to perform administrative tasks before terminating the session. In addition, a variety of other functions including memory management functions to allocate and free memory space for a session may be provided. Typically, memory allocation functions are provided by the administrative client and memory is allocated and released by the administrative client for a logical session. Fig. 9 illustrates a typical, general-purpose computer system 900 suitable for implementing the present invention. The computer system 900 includes any number of processors 902 (also referred to as central processing units, or CPUs) that are coupled to memory devices including primary storage devices 904 (typically a read only memory, or ROM) and primary storage devices 906 (typically a random access memory, or RAM).

Computer system 900 or, more specifically, CPUs 902, may be arranged to support a virtual machine, as will be appreciated by those skilled in the art. One example of a virtual machine that is supported on computer system 900 will be described below with reference to Fig. 9. As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPUs 902, while RAM is used typically to transfer data and instructions in a bi-directional manner. CPUs 902 may generally include any number of processors. Both primary storage devices 904, 906 may include any suitable computer-readable media. A secondary storage medium 908, which is typically a mass memory device, is also coupled bi-directionally to CPUs 902 and provides additional data storage capacity. The mass memory device 908 is a computer- readable medium that may be used to store programs including computer code, data, and the like. Typically, mass memory device 908 is a storage medium such as a hard disk or a tape which generally slower than primary storage devices 904, 906. Mass memory storage device 908 may take the form of a magnetic or paper tape reader or some other well-known device. It will be appreciated that the information retained within the mass memory device 908, may, in appropriate cases, be incorporated in standard fashion as part of RAM 906 as virtual memory. A specific primary storage device 904 such as a CD-ROM may also pass data uni-directionally to the CPUs 902. CPUs 902 are also coupled to one or more input/output devices 910 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well- known input devices such as, of course, other computers. Finally, CPUs 902 optionally may be coupled to a computer or telecommunications network, e.g., an Internet network or an intranet network, using a network connection as shown generally at 912. With such a network connection, it is contemplated that the CPUs 902 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using CPUs 902, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.

Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the present invention. By way of example, operations involved in performing an administrative task may be removed or added without departing from the spirit or the scope of the present invention. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. What is claimed is:

Claims

hi the claims:

1. In an electronic mail messaging system having a mail server, an apparatus for delegating email service administration, comprising: a mail administrative delegator coupled to the mail server configured to delegate an administrative function associated with the electronic mail services provided by the mail server to the at least one entity.

2. An electronic mail messaging system as recited in claim 1, wherein the electronic mail server provides mail services to at least one entity through one or more virtual host domains.

3. An electronic mail messaging system as recited in claim 1, wherein the at least one entity is a remote entity with respect to the mail server.

4. An electronic mail messaging system as recited in claim 1, wherein the delegated administrative function is selected from the list comprising: adding a mailbox, deleting a mailbox, reading mail information and modifying mail information

5. An electronic mail messaging system as recited in claim 4, wherein the delegated administrative function is associated with a single user, a group of users, or a distribution list.

6. An electronic mail messaging system as recited in claim 5, wherein the at least one entity is provided with a graphical user interface to perform an administrative task that is related to the delegated function.

7. An electronic mail messaging system as recited in claim 1, wherein the mail administrative delegator provides an authentication service and an error handling service.

8. A mail administrative delegator included in an electronic mail messaging system, comprising: an administrative client; an administrative server; and an application programming interface for the administrative server.

9. A mail administrative delegator as recited in claim 8, wherein the administrative client is a library of high level functions that can be used to perform an administrative task; wherein the administrative client performs a remote procedure call to the administrative server; and wherein the administrative server access directory services of the mail server to perform the administrative task.

10. A mail administrative delegator as recited in claim 9, wherein the administrative server provides a handle that can be used by the client to perform one or more successive administrative tasks.

11. In an electronic mail messaging system, a method for performing administrative tasks remotely, the administrative tasks being associated with electronic mail services provided by a mail server, the electronic mail server operating to provide mail services to at least one entity, the method comprising: initiating a remote connection; establishing a remote connection; initiating an admimstrative task; calling a client function; calling one or more client procedure to perform the client function; and performing the administrative task.

12. A method as recited in claim 11, wherein the method further comprises: authenticating the remote connection before allowing the establishing of the remote comiection

13. A method as recited in claim 11 , wherein the method further comprises: disconnecting the remote connection.

14. A method as recited in claim 13, wherein the disconnecting of the remote connection is provided by a logout procedure.

15. A method as recited in claim 14, wherein the initiating of the remote connection is provided by a login procedure.

16. A method as recited in claim 13, wherein the administrative task can be adding, deleting, reading or modifying mail information with respect to single users, group users, and distribution lists.

17. A computer readable media including computer program code, said computer readable media comprising: computer program code for initiating a remote connection; computer program code for establishing a remote connection; computer program code for initiating an administrative task; computer program code for calling a client function; computer program code for calling one or more client procedure to perform the client function; and computer program code for performing the administrative task.

18. A computer readable media as recited in claim 17, wherein the computer readable media further comprises: authenticating the remote connection before allowing the establishing of the remote connection.

19. A computer readable media as recited in claim 17, wherein the computer readable media further comprises: disconnecting the remote connection.

20. A computer readable media as recited in claim 17, wherein the administrative task can be adding, deleting, reading or modifying mail information with respect to single users, group users, and distribution lists.