`Srivastava et al.
`
`I IIIII IIIIIIII Ill lllll lllll lllll lllll lllll lllll lllll lllll llllll llll llll llll
`
`( JOJ Patent No.:
`(45) Date of Patent:
`
`US006374292B 1
`US 6,374,292 Bl
`Apr. 16, 2002
`
`(54) ACCESS CONTROL SYSTEM FOR AN ISP
`HOSTED SHARED EMAIL SERVER
`
`(75)
`
`Inventors: Anil K. Srivastava, Redwood City;
`Timothy C. Misner, Palo Alto; Daryl
`A. Huff, Saratoga, all of CA (US)
`
`(73) Assignee: Sun Microsystems, Inc., Palo Alto, CA
`(US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35 ·
`U.S.C. 154(b) by O days.
`
`(21) Appl. No.: 09/520,864
`
`(22) Filed:
`
`Mar. 7, 2000
`
`Related U.S. Application Data
`(60) Provisional application No. 60/144,709, filed on Jul. 20.
`1999.
`Int. Cl.7 ................................................ G06F 15/16
`(51)
`(52) U.S. Cl. ........................ 709/206; 709/229; 713/201
`(58) Field of Search ................................. 709/206. 229,
`709/223; 707/9; 713/155-158, 201; 340/5.5,
`5.74; 705/5; 345/741-743
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,263.157 A * 11/1993 Janis ..... ....... ....... .. ........ 707 /9
`5,649,099 A * 7/1997 Theimer et al.
`............ 713/201
`5,706.349 A * 1/1998 Aditham et al. .............. 380/25
`5,751,791 A
`5/1998 Chen et al.
`5,765,033 A
`6/1998 Miloslavsky
`5,768,505 A
`6/1998 Gilchrist et al.
`5.835.727 A * 11/1998 Wong et al. ................ 709/238
`5,884,046 A
`3/1999 Antonov
`6/1999 Call
`5,913.210 A
`
`7/1999 Masters et al.
`5.920,697 A
`5,938.729 A
`8/1999 Cote et al.
`6,012.088 A
`1/2000 Li et al.
`6,105,027 A * 8/2000 Schneider et al. ............. 707/9
`6.131.095 A
`10/2000 Low et al.
`6,154,738 A
`l 1/2000 Call
`6,163,805 A
`12/2000 Silva et al.
`6, l 75,832 BI
`1/2001 Luzzi et al.
`6,199,062 Bl
`3/2001 Byrne et al.
`
`OTHER PUBLICATIONS
`
`Newton, H., Newton's Telecom Dictionary, Telecom Books,
`pp. 24fr247, Oct. 1998.*
`International Search Report from Corresponding PCT
`Application PCT/USOl/07298.
`International Search Report from Corresponding PCT
`Application PCT/USO 1/07097.
`* cited by examiner
`Prima,y Examiner-Zarni Maung
`Assistant Examiner-Andrew Caldwell
`(74) Attorney, Agent, or Firm-Beyer Weaver & Thomas
`LLP
`
`(57)
`
`ABSTRACT
`
`Precedence rules that govern the granting of user level
`services for a domain in a shared mail server for an email
`provider are disclosed. Accordingly, when a request for the
`user level service is made, a determination is made whether
`or not the requested service is a member of a proper set of
`allowed domain level services. If the requested user level
`service is within the proper set of allowed domain level
`services, then the requested user level service is granted. In
`so doing, the granted user level service becomes a member
`of the proper subset of the set of allowed domain level
`services for the shared mail server.
`
`8 Claims, 6 Drawing Sheets
`
`608
`
`defme allowed serv1cP!. a!.
`1ntersec11on ol domain
`
`- 614
`
`616
`
`606
`
`610
`
`61:?
`
`600
`
`Twitter Exhibit 1030
`Twitter, Inc. v. BlackBerry Ltd.
`Page 00001
`
`
`
`~
`
`t:=
`N
`\0
`
`-...,l .. 'N
`
`1H
`O'I
`rJ1
`d
`
`~
`
`'""" 0 ...,
`rr,. =-a
`
`N g
`'""" ~~
`:'1
`"Cl
`>
`
`N
`
`~ = .....
`~ .....
`
`•
`00
`0 •
`
`Prior Art
`Fig. 1
`
`100
`
`\
`
`-_,
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`-
`
`I--
`
`~-------------------------------------------------------------:
`
`firewall
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`u
`
`105
`
`IP router
`
`relay
`SMTP
`
`112
`
`110
`DNS
`
`108
`
`----------------~-----------------------------------------
`
`IP router
`
`105
`
`(ISP) 104
`
`Internet Service Provider
`
`firewall 107
`
`LAN
`
`user
`
`user
`
`102-n
`
`• • •
`
`106
`
`IP router
`
`105
`
`firewall 107
`
`LAN
`
`,_)02-1
`
`user
`
`user
`
`Page 00002
`
`
`
`U.S. Patent
`U.S. Patent
`
`Apr. 16, 2002
`Apr. 16, 2002
`
`Sheet 2 of 6
`Sheet2 of6
`
`US 6,374,292 Bl
`US 6,374,292 B1
`
`
`~,
`·~ rn[J
`directoryservices [ie
`
`
`302transferunit
` message
`
`"'O
`
`314
`
`N .
`O>
`LL
`
`Fig.2
`
`I...
`Q)
`"'O
`C
`Q) rn
`
`sender
`
`Page 00003
`
`o| %
`
`©o
`
`0 Q)
`-
`0
`
`O
`
`ai ·~ M
`·= Q)
`rn
`
`N 91
`
`Page 00003
`
`
`
`c=
`N
`~
`'N
`~
`~
`~
`C/"J.
`d
`
`i,,-
`
`~
`
`s,
`00 =-~ ....
`
`l',M
`
`~ s
`
`9"
`1-""
`
`> ~ :,
`
`~ .....
`~ .....
`
`•
`rJ).
`
`0 •
`
`302
`unit
`
`transfer
`
`cl
`tr
`
`\
`
`-
`
`t '-delivery
`i message
`
`304
`
`message store
`
`folders
`shared
`
`folder
`private
`
`-
`
`inbox
`
`~
`
`......
`
`....
`
`-
`
`~
`
`......
`
`-
`
`....
`.___
`
`mailbox
`user2
`
`L index ~ ....
`
`JI'
`404
`
`468
`
`1--
`
`folders
`shared
`
`1--
`
`folder
`private
`
`-.
`
`...
`
`406
`/
`
`......
`,___,
`
`402
`inbox
`
`_..--
`
`Fig. 3
`
`304~
`
`I -....
`
`-mailbox
`user1
`
`401
`
`.~
`
`~ ......
`
`services
`access
`message
`
`-
`
`retrieval and disposition
`
`retrieval --tJ
`message I[
`
`Page 00004
`
`
`
`U.S. Patent
`
`Apr. 16, 2002
`
`Sheet 4 of 6
`
`US 6,374,292 Bl
`
`500
`~
`
`define virtual domain node
`in DIT
`
`define routing table entries
`based upon newly defined
`virtual domain node in DIT
`
`associate virtual domain
`attributes with virtual
`domain node
`
`502
`
`504
`
`506
`
`done
`
`Fig. 4
`
`Page 00005
`
`
`
`U.S. Patent
`
`Apr. 16, 2002
`
`Sheet 5 of 6
`
`US 6,374,292 Bl
`
`set domain
`services
`
`get user service
`
`602
`
`604
`
`608
`
`606
`
`no
`
`define allowed services as
`intersection of domain
`services and user services
`
`yes
`
`allowed user services set
`to domain services
`
`no
`
`error
`
`614
`
`yes
`
`confirm user
`service
`
`616
`
`610
`
`612
`
`I
`
`600
`
`Fig. 5
`
`Page 00006
`
`
`
`U.S. Patent
`
`Apr. 16, 2002
`
`Sheet 6 of 6
`
`US 6,374,292 Bl
`
`700
`
`\
`
`: ROM r--,
`-~-I
`l __ 704 _
`
`I
`
`I
`
`RAM
`706
`
`CPU
`702
`
`MASS STORAGE
`708
`
`)
`
`i· I
`1/0 DEVICE
`710
`
`Figure 6
`Prior Art
`
`Page 00007
`
`
`
`US 6,374,292 B 1
`
`1
`ACCESS CONTROL SYSTEM FOR AN ISP
`HOSTED SHARED EMAIL SERVER
`
`CROSS-REFERENCE TO A RELATED
`APPLICATION
`
`This application takes priority under 35 U.S.C. § l l 9(e) of
`U.S. patent application Ser. No. 60/144,709 filed Jul. 20,
`1999 naming Daryl Huff, et al. as inventor(s) and assigned
`to the assignee of the present application which is al so
`incorporated herein by reference for all purposes. This
`application is also related to the following co-pending U.S.
`Patent applications, which are filed concurrently with this
`application and each of which are herein incorporated by
`reference, (i) U.S. patent application Ser. No. 09/519,964,
`entitled "Methods and Apparatus for Automatically Gener(cid:173)
`ating a Routing Table in a Messaging Server" naming
`Belissent et al a~ inventors; (ii) U.S. patent application Ser.
`No. 09/521.282, entitled "Methods and Apparatus for Pro(cid:173)
`viding a Virtual Host in Electronic Messaging Servers"
`naming Belissent et al as inventors; (iii) U.S. patent appli(cid:173)
`cation Ser. No. 09/520,865, entitled "Methods and Appara(cid:173)
`tus for Monitoring Electronic Mail Systems" naming
`Kavacheri et al as inventors; and (iv) U.S. patent application
`Ser. No. 09/519,948, entitled "Methods and Apparatus for 25
`Delegating Administrative Capabilities to Domains Served
`by Email Provider" naming Abbott et al a~ inventors.
`
`2
`("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
`5 businesses 102 also operate and maintain their own appli(cid:173)
`cation 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
`mll~t operate through a firewall that filters out undesirable
`10 packets and insulates the organization's internal network
`from the Internet. Notice that for many organizations, espe(cid:173)
`cially small ones, the email server may actually be the
`firewall system.
`In the email system 100, those consumers and/or busi-
`15 nesses 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 desig-
`20 nate as the root server for all consumers and/or businesses,
`act as a primary master server for consumers and/or busi(cid:173)
`nesses 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
`30 consumer's email when their mail server is down. However,
`unfortunately, the relay host imposes a significant manage(cid:173)
`ment 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
`35 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
`4o 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.
`45 (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, connect~ to a
`so 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 i.s not cost effective for
`small domains. In addition, as the number of domains
`increases. the management of the individual services
`becomes increa~ingly 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
`65 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
`
`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 particu(cid:173)
`larly still, the present invention is directed towards a method
`and apparatus for defining a virtual domain 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 a~sistants (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 i.s typically located on the server 55
`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 60
`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 con(cid:173)
`sumers and/or businesses 102-1 ("abc.com") through 102-n
`
`Page 00008
`
`
`
`US 6,374,292 Bl
`
`3
`which. in turn. can support many different domains associ(cid:173)
`ated with consumers and/or businesses is desirable.
`However. when the users within a domain are granted a
`particular set of user level services. that set of user level
`services must be a proper subset of the associated allowed 5
`set of domain services.
`Therefore. what is desired is a set of precedence rules that
`govern the granting of user level for a particular domain
`having a set of domain services.
`
`lO
`
`SUMMARY OF THE INVENTION
`
`To achieve the foregoing, and in accordance with the
`purpose of the present invention. methods for granting a user
`level service based upon a set of allowed domain level
`services is provided. In accordance with one aspect of the
`present invention. a method is disclosed where a requested
`user level service is granted or not based won a set of
`allowed domain level services. The user level service is
`requested and a subsequent determination is made whether 20
`or not the requested user level service is a member of a
`proper subset of the set of allowed domain level services. If
`the requested service is determined to be a member of the
`proper subset of allowed domain level services, then the
`requested user level service is granted. In so doing, the 25
`granted user level services becomes a member of a set of
`allowed user level services.
`
`4
`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 infra(cid:173)
`structure in the 1990s, organizations are seeking messaging
`solutions that provide a lower cost of ownership while
`increasing the effectiveness and reliability of their commu(cid:173)
`nications network. Specifically, they are evaluating the ben-
`efits of Internet standards-based messaging systems.
`Broadly speaking, the invention describes an Internet
`standards-based messaging system having a mail server
`capable of offering e-mail 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
`15 and host them on a shared mail server.
`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
`Internet 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-
`30 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 auto(cid:173)
`matically handles the receiving of mail messages necessi-
`tated 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
`40 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
`45 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 con-
`50 forn1s to RFC 822 specifications, and recognizes the Mul(cid:173)
`tipurpose 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
`55 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
`60 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
`65 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
`
`35
`
`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 accom(cid:173)
`panying 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 a flowchart that details a process that
`applies a set of precedence rules to the granting of user-level
`in accordance with an embodiment of the invention.
`FIG. 6 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
`
`Page 00009
`
`
`
`US 6,374,292 Bl
`
`5
`
`5
`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 mes(cid:173)
`sage 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 connec(cid:173)
`tion is handled by a thread. In this way, multithreaded access
`maximizes both performance and scalability by minimizing
`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 tum 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 metainformation: user
`profiles, distribution lists, and other system resources based
`upon, in some embodiments, a dedicated Lightweight Direc(cid:173)
`tory Access Protocol (LDAP) directory service. This direc(cid:173)
`tory 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 organi(cid:173)
`zation. 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. In
`addition, since the information stored in the directory ser(cid:173)
`vice 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, 65
`message access servers (MAS) can read messages from only
`a designated one of them. The transfer unit 302 uses these to
`
`6
`determine the targets of message delivery for all messages
`submitted to a particular distribution list. Such 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
`10 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
`15 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
`20 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
`25 transport and protocol combination has an associated trans(cid:173)
`fer 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
`30 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
`35 is so configured using configuration data stored in a con(cid:173)
`figuration 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
`40 their messages and the transfer unit 302 automatically routes
`and delivers them appropriately.
`In most embodiments, the transfer unit 302 stores mes(cid:173)
`sages as text files. Messages with multiple parts possibly
`containing different types of data) are represented as a series
`45 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 con(cid:173)
`tains transport information. The message envelope is termi(cid:173)
`nated by a line containing a boundary marker, or by a line
`50 containing two CTRUA 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
`55 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
`60 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 bv a colon then a value which can be generated by,
`for exampl~. 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
`
`Page 00010
`
`
`
`US 6,374,292 BI
`
`10
`
`45
`
`7
`and to actually deliver the message to the message store adds
`a return-path header. The received and return-path headers
`provides inforn1ation 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 infom1ation. 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 Jogging into their mailboxes. The mes(cid:173)
`sage store 304 also obtains information about user message
`quota limits and message store type (IMAP or POP). Out(cid:173)
`going 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 direc(cid:173)
`tory 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 the virtual domain node has been defined. correspond(cid:173)
`ing routing table entries are defined at 504 and at 506,
`various virtual domain are stored at the virtual domain node.
`It should be noted that the various virtual domain include a
`list of services permitted the domain. Such services include
`IMAP. MAPS, POP3, POP3S, SMTP which in some cases
`requires presentation of credentials. Other of the services
`include identification of a domain administrator who is
`authorized to manage the particular virtual domain which
`includes setting particular user-level for particular users in
`the domain. These services also include designation of a
`virtual domain postmaster who identifies email message
`delivery problems, and a state of the domain.
`In a preferred embodiment, the state of the domain can be
`active indicating that all mail can be received, or the state
`can be inactive. where the particular domain has been
`temporarily suspended for various and sundry reasons. or.
`the state of the domain can be deleted indicating that the
`particular domain no longer exists.
`Referring now to FIG. 5 that illustrates a flowchart that
`details a process 600 that applies a set of precedence rules
`to the granting of user-level serves in accordance with an
`embodiment of the invention. The process 600 begins at 602
`establishing a set of domain services for the domain. At 604,
`a set of user level services is obtained for a user within the 65
`domain. At 606. a determination is made whether or not the
`set of user level services is a null set. If the set of user level
`
`8
`services is not a null set (i.e., certain user lever services have
`been defined), glen a set of allowed services is defined as an
`intersection of the set of user level services and the set of
`domain services at 608. If, however, the set of user level
`s services is determined to be a null set (i.e., there are no
`- defined user level services), then the allowed set of user
`level services is defined as the set of domain services. In
`either case, control is passed to 612 where it is determined
`if the requested user level service a member of the set of
`allowed user level services. If it is determined tat the
`requested service is not a member of the set of allowed user
`level services, then an error flag is thrown at 614. Otherwise,
`the requested user level service is confirmed at 616.
`FIG. 6 illustrates a typical, general-purpose computer
`system 700 sui