How POP3 Service Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How POP3 Service Works

In this section

• POP3 Architecture

• POP3 Protocol

• POP3 Physical Structure

• POP3 Processes and Interactions

• Network Ports Used by POP3

• Related Information

The POP3 service enables a server to host e-mail accounts and includes tools to administer the servers, domains, and mailboxes.

The POP3 service performs the tasks of message download and request handling on a Windows-based server, where message download consists of transmitting the messages from a folder in the file system to clients and request handling is performed according to the POP3 protocol, which defines how the server responds to requests sent from an e-mail client.

The SMTP service receives e-mail from the Internet, saves the e-mail to the Queue folder, and notifies the SMTP delivery service for POP3 of the arrival of e-mail. The delivery service then moves the e-mail to the POP3 mail store, where it is available for download to POP3 e-mail clients.

The ideal environment for the POP3 service consists of the following:

• Windows Server 2003 is installed and functioning properly.

• Server hardware is sized appropriately for the number of users and disk space requirements.

• A suitable authentication configuration for the installation is implemented, using, Active Directory integrated, local Windows accounts or encrypted password file authentication.

• The volume that holds the mail store is formatted with the NTFS file system.

• Quotas are enabled on the volume that will host the mailboxes.

• The Internet domain name is registered with a naming authority.

• The SMTP service is configured as a mail exchange host with the Internet Service Provider.

• Mail Exchanger (MX) records have propagated through the Domain Name System.

Note

• Mail Exchanger (MX) records and mail exchange host configurations are not required for all installations. Consult your ISP to determine how your server should be configured.

This section covers how the service works with existing services and components of Windows Server 2003. The POP3 protocol is presented to explain the command set implemented by the POP3 service. The physical structure of the POP3 e-mail system and the mail store is shown to illustrate the processes and interactions of the POP3 service and the SMTP service.

POP3 Architecture

The POP3 service uses the SMTP service, an existing component of Internet Information Services (IIS), to provide inbound message delivery as well as outbound message sending for POP3 clients. The figure POP3 Architecture shows the modularity of the POP3 service and the relationship with IIS and the file system.

POP3 Architecture

The POP3 service is the interface between e-mail clients and the mail store. POP3 listens on TCP port 110 for connections from e-mail clients, authenticates the client, and manages the connection with the client.

The authentication store is the repository of user information needed to authenticate the user. The store can be the Active Directory database, the local SAM database, or the encrypted password file for the user. The authentication module accesses the authentication store to verify the credentials submitted by the client to the POP3 service.

The Mail Storage Access API is the common interface to the mail store for all processes. The POP3 service, the SMTP delivery service for POP3, and the POP3 Server Administrator use the API to access the mail store.

The mail store uses the file system for storage. The mail store is typically located on the same server as the POP3 service, but it should be located on a different local or network volume than the operating system to avoid potential disk space problems. For large mail stores, the mail store can be placed on a Network Attached Storage (NAS) device and accessed by one or more servers running the POP3 service. Even though the mail store is contained in the file system, it is accessed by using the Mail Storage Access API.

The SMTP delivery service for POP3 is the component that transfers e-mail from the SMTP service to the user mailboxes. The delivery service is notified by the SMTP service when new e-mail arrives. New e-mail is delivered to the mail store by means of the Mail Storage Access API.

The POP3 Server Administrator is the interface used by the tools to configure the server, domains, and mailboxes. The server administrator accesses the mail store by means of the Mail Storage Access API to create or modify domains and mailboxes. Modifications to the service itself are made through calls to the administration interface within the POP3 service.

With the exception of the authentication store, the installation of the POP3 service installs all of the components shown in the figure POP3 Architecture. The POP3 service installation copies the files to the server and registers the dynamic-link libraries. The file names are listed in the table POP3 Components along with a description of the file. The files are copied to the systemroot\system32\pop3server directory, unless noted otherwise, and the installation path is added to the system path variable.

The following table lists the components of the POP3 service.

POP3 Components

Component	Description
P3admin.dll	The interface to the mail store that supports the creation, deletion, verification, and renaming of mailboxes and domains. The POP3 Server Administrator uses this functionality.
P3store.dll	The interface to the mail store that supports mailbox locking, message creation and deletion, and creation, modification, and retrieval of the hashed password. The POP3 service, SMTP delivery service for POP3, and POP3 Server Administrator use this functionality.
Pop3auth.dll	The interface to the authentication methods.
Pop3evt.dll	The interface to the System log.
Pop3svc.exe	The Microsoft POP3 Service, which is started by the Service Control Manager. Pop3svc initializes the socket and thread pools, starts the listener, and manages the client connections to the service.
Winpop.exe	Command line tool to administer the POP3 service. Installation location is systemroot\system32.
P3server.msc	POP3 service console file used when the Microsoft Management Console (MMC) console is used. Installation location is systemroot\system32.
Pop3perf.dll	Contains methods that collect performance counter data from the POP3 service and make it available for display in the System Monitor.
Pop3pi.h	Header file that contains the list of performance counter indices used by the POP3 service.
Pop3snap.dll	The interface to the MMC.
Pop3perf.ini	Initialization files for the performance counters, which are not dynamically initialized.

POP3 Protocol

The POP3 protocol is an application layer protocol, similar to the SMTP in the figure POP3 Protocol Architecture. Since POP3 uses TCP as the transport layer, it belongs on the same side of the figure as SMTP.

POP3 Protocol Architecture

RFC 1939, “Post Office Protocol -Version 3” defines a set of commands and responses for accessing a mailbox on a server and retrieving the messages. The POP3 service implements RFC 1939.

The POP3 protocol defines not only the commands and responses between a POP3 client and server but also the state of the session. The state of the session defines whether a POP3 command is valid in that context. The protocol defines commands for authentication, message retrieval, and message management in a series of three states. The three states of a POP3 session are:

• Authorization

• Transaction

• Update

POP3 commands submitted by the POP3 client are valid only in the context of the current state and the state changes as the session progresses. Typically, session state progresses from the authorization state, to the transaction state, and finally to the update state. However, a session can go from the authorization state to being disconnected if a client sends the QUIT command while in the authorization state.

The authorization state is the state of the session once a connection has been established. The connection between the client and server uses the TCP three-way handshake to establish a network connection. The table Authorization State lists the commands sent by the client to the POP3 server.

Authorization State

Command	Description
USER username	Requires an argument that specifies the mailbox name. The USER command is used when plaintext authentication is allowed.
PASS password	Must be preceded by the USER command. Requires the argument that specifies the password for the mailbox account. The response will indicate logon failure if an incorrect password was supplied, another user is already logged on to the mailbox, or the account is otherwise locked.
AUTH or AUTH [NTLM|APOP]	If no argument is passed by the client, the response from the server contains the authentication methods in effect. The POP3 service accepts NTLM or APOP as valid arguments.

The transaction state is the second state of the POP3 session. The commands valid in the transaction state provide information about the e-mail messages, return the contents of the messages, and mark the messages for deletion. The table Transaction State lists the commands sent by the client to the POP3 server. The commands in the table are valid when the POP3 session is in the transaction state.

Transaction State

Command	Description
STAT	Returns a response with the number of messages in the mailbox and the byte count for each message.
LIST or LIST n	If no argument is supplied, the server returns a listing for each message containing the message length and message marker. If an argument is supplied, the server returns a listing for the specified message, it if exists.
RETR n	Returns the contents of the specified message, if it exists and has not been previously marked for deletion. Returns an error if no message id is specified.
DELE n	Returns a success response if the argument is an existing message not previously marked for deletion. This command does not delete the message.
NOOP	Returns a positive response but the server performs no action.
RSET	Returns a positive response after it removes the deletion mark from messages previously marked for deletion.
TOP n	Returns the number of specified lines of a message not previously marked for deletion.
UIDL or UIDL n	Returns a globally-unique identifier (GUID) for each message in the mailbox or a specified message, if the message was not previously marked for deletion.

The update state is the last state of a POP3 session. The receipt of the QUIT command signals the server to delete any messages marked for deletion. The QUIT command can also be used in the authorization state to end a session before it enters the transaction state. In this situation, the connection to the server is terminated. For more information about the POP3 protocol, see RFC 1939.

Note

• Messages were marked for deletion in the transaction state by the DELE command. The actual deletion did not occur when the messages were marked for deletion.

The table Update State lists the single command sent by the client to end the session. The server displays the greeting message in response to this command.

Update State

Command	Description
QUIT	Causes the greeting message to be displayed. Any messages previously marked for deletion by the DELE command are deleted when the QUIT is sent.

POP3 Physical Structure

The physical structure of the POP3 mail system is shown in the figure Physical Structure of E-mail Systems. It shows both end systems running the POP3 and SMTP service. A message is shown as it travels from the sender through the Internet to the destination by using the protocols shown.

Physical Structure of E-mail Systems

The major components of the physical structure are client systems, mail servers, and the Internet. A client system can be a personal computer, laptop, or personal digital assistant. The client system must have a POP3 client capable of communicating with an SMTP service for sending mail and a POP3 service for receiving mail. The typical client configuration includes a setting for the SMTP server and the POP3 server, either as IP addresses or as resolvable host names.

The servers are shown with an SMTP service to send mail to and receive mail from the Internet. The Internet provides the backbone of networks used to carry the message from the originating system to the destination system. The delivery service, which is not shown, is used to deliver mail to the POP3 mailboxes.

The SMTP service and SMTP delivery service for POP3 work together to deliver a message sent by means of the Internet. As shown in the figure, all message transmission uses the SMTP protocol until the message reaches the destination host. The POP3 protocol is used by the POP3 service to download e-mail messages to the client.

Various Installations of the POP3 Service

The most common POP3 server installation is shown in the figure Typical POP3 Server Installation. The POP3 service and the message store are on one server and the mail store is on a volume on the same server.

Typical POP3 Server Installation

The clients shown in the figure connect to the single server. The POP3 service and the message store are on the server and the mail store is on a volume on the same server. Ideally, the mail store is located on a separate volume from the operating system. The processes and interactions of the server are contained within the server, with the possible exception of the authentication routines, which might make calls to other servers depending on the authentication method employed by the POP3 service.

The use of a remote store with the POP3 service is shown in the figure POP3 Server with Remote Store. The remote store is a NAS device that provides large message stores with room to grow.

POP3 Server with Remote Mail Store

In this installation, the mail store is accessing a disk that is on a NAS device. This installation also supports one or more domains and all clients access a single server to retrieve e-mail. The advantage of this installation is the ability to grow the store as needed, as long as the hardware is capable of adequately supporting the user’s. Any incoming e-mail to the POP3 users from the Internet is delivered to the SMTP service on the POP3 server and written to the mail store on the NAS device.

In the figure Multiple POP3 Servers, three servers access a remote store on a NAS device. The POP3 clients connect to different servers to balance the load across the servers. Adding more servers allows the POP3 service to support more users and provides a level of redundancy.

Multiple POP3 Servers

The only notable difference in this installation is that any incoming e-mail to the POP3 servers from the Internet is delivered to the SMTP server designated to receive e-mail for the domain, which then delivers the mail to the POP3 mail store. Any outbound messages are delivered to the Internet by the SMTP server designated for this purpose, although the same server typically receives and sends messages for a domain. Because there is more than one POP3 server, a server should be assigned the task of receiving inbound e-mail.

Note

• If you are using encrypted password file authentication, you must use the same globally unique identifier (GUID) on each mail server. To do so, select one mail server, identify its GUID, and then configure all other mail servers to use the same GUID.

POP3 Processes and Interactions

The mail delivery process is how e-mail travels from the originating server to the destination server. The process described in the figure POP3 E-mail Delivery shows the steps and the protocol used for each leg of the journey.

POP3 E-mail Delivery

In the figure POP3 E-mail Delivery, e-mail is sent to someone@example.com.

1. The e-mail is submitted for the user someone@example.com.

2. The SMTP service resolves the e-mail domain, example.com, to a mail server on the Internet, mailserver1.example.com.

3. E-mail is routed to the example.com domain where it is received by the SMTP service on mailserver1.example.com.

4. The SMTP service places the e-mail in the Queue folder on the destination mail server. The delivery service is notified of new e-mail for the domain example.com.

5. The delivery service moves e-mail to the recipients mailbox, P3_someone.mbx, in the mail store.

6. The user checks for e-mail by connecting to the mailbox for someone@example.com. The POP3 service verifies the credentials for the user and then either accepts or denies the connection.

7. If the user authenticates successfully, the e-mail is downloaded to the user’s computer.

Preparing to Retrieve E-Mail

The POP3 service initializes its resources when the service is started by the Service Control Manager. Before the service can accept requests, it must do the following:

• Initialize the endpoint for connections and listen for requests

• Create a thread pool

• Create a socket pool

Listening for Connection Requests

In order for clients to connect to the service, the server must listen on some communication endpoint for a connection request. The POP3 service listens, by default, on TCP port 110 for incoming connections, unless it is configured to listen on another port. The service expects clients connecting to the POP3 service to use the POP3 protocol during the session. When a TCP connection is established, the server sends a greeting message that identifies itself as a POP3 server. In the past, attempts have been made to exploit vulnerabilities in software using the version information included in the greeting message. The greeting message can be configured to hide system information.

Creating a POP3 Service Thread Pool

The POP3 service creates a pool of threads at initialization that wait on the I/O Completion Port for I/O Completion packets. I/O completion ports are used when thread pools process asynchronous I/O requests for an application. When an I/O Completion packet is posted to the port, the packet is passed to a thread to perform work for the packet. The I/O Completion packet has a handle to a data structure called the I/O Context. The I/O Context contains information about the type of I/O, callback functions, and other information specific to the type of object, such as an inactivity timer.

Creating a POP3 Service Socket Pool

The POP3 service creates a pool of sockets to handle incoming connection requests. While the service is running, the service maintains a pool of sockets sufficient to handle the connection requests while not consuming resources needlessly. There are four settings that are specific to the socket pool. The first setting is the minimum number of sockets that the POP3 service creates at startup. The socketmin setting is chosen to support a reasonable number of connections and allow the server to start up quickly. The default value of socketmin is 10.

The socketthreshold value is the number of unused sockets in the pool; the socketthreshold value is also the size of the block of sockets to create when new sockets are created. When the number of sockets remaining in the pool reaches the socketthreshold value, the server adds more sockets to the pool in anticipation of connection requests. If the threshold value is reached, the POP3 service creates new sockets in increments equal to the threshold setting size. If the socketthreshold value is greater than the remaining number of sockets until the maximum value is reached, the service will create only as many sockets as possible. The default value is 5.

The maximum number of sockets, socketmax, is the total number of sockets the POP3 service will create. As the POP3 service increase the size of the pool, the number of sockets will approach the maximum value. Once the maximum setting is reached, the POP3 service will not create any additional sockets. At this point, any incoming requests are placed in a queue. The size of the queue is determined by the socketbacklog setting. If the number of connections exceeds the number represented by socketmax +socketbacklog, any incoming connection requests are refused.

When a connection is closed, the socket is closed and the total number of sockets in use is decremented by 1. If the total number of available sockets is less than socketthreshold and socketmax, a new block of sockets is created. The server always maintains a sufficient number of sockets for incoming connections.

Note

• The POP3 service manages connections to the server and automatically disconnects idle connections.

Storing Messages

The POP3 mail store maintains an organizational structure of message domains and mailboxes for the POP3 service, using the existing file system on the server. This organizational structure permits the POP3 service to host a single e-mail domain or many e-mail domains on a server. Mail domains are folders in the file system that exist at the same level in the directory and contain any mailboxes created in the domain. Mailboxes contain the e-mail messages for the recipient.

Mail Store

The mail store is a directory on the local file system or a Universal Naming Convention (UNC) path, or the mail store can exist on a NAS device. In the latter configuration, multiple POP3 servers can access the same mail store. The POP3 service can use the FAT file system but the recommended file system is NTFS. By using NTFS, the mail store offers logging, recovery, and disk quotas. In the event of a server crash, NTFS can recover data by replaying its log files.

Disk quotas are a feature of the NTFS file system that can be helpful for managing the POP3 mail store. The POP3 mail store is not a single-instance storage system, in which the server keeps only a single copy of a message and a separate table of recipients indexed by a message identifier. When a single-instance storage system stores a message sent to more than one recipient on a server, the recipient’s access the same instance of the message in the mail store. When one recipient deletes the message, the message remains in the mail store until all other recipients have deleted the message.

When a message is received by the SMTP service, each recipient of a message receives a separate copy of the message from the delivery service. The use of disk quotas ensures that individual mailboxes and the mail store in general do not use excessive or unanticipated amounts of disk space and adversely affect the performance of the POP3 service or the server. A disk use policy that encourages users to download messages to a local disk and not use the POP3 mail store as a permanent storage location can be implemented through the use of disk quotas.

Mail Root

The mail root is the first organizational segment, shown in the figure Mail Store. The POP3 mail root is a directory path that identifies the first part of the path to the mail store. By default, the mail root is defined as system_drive\InetPub\Mailroot\Mailbox. All domains will be created under the mail root.

Mail Domain

The mail domain is the second segment of the organizational structure. When a domain is created by one of the configuration tools, the directory is created under the mail root. The domain name must be unique within the mail root and as a property of the SMTP service, where the domain is stored as a property in the IIS metabase. The domain name must:

• Have fewer than 255 characters

• Consist of alphabetic and numeric characters in the set {a-z, 0-9, -}

• Be registered with an Internet Naming Authority

Mailbox

The mailbox is the third segment of the organizational structure. The mailboxes are shown in the diagram as the folders on the right hand side. The mailboxes for a domain are logically grouped together by the domain because the path to the mailbox includes the domain name. Mailboxes for user accounts are created in a directory in a POP3 domain to hold the e-mail message delivered by the SMTP delivery service for POP3. The organizational structure permits mailbox names to be used more than once in different domains so a new domain can have mailboxes with the same names as those shown in the diagram. The mailbox folder name is P3_mailbox name.mbx, where the mailbox name must:

• Have fewer than 64 characters

• Cannot consist of characters in the set {@ ( ) / \ [ ] : ; , " . * = | ? + }

• Be unique in the context of the domain

When a mailbox is created, it has the following contents:

• Lock file

• Quota file

The mailbox lock file prevents simultaneous access to the mailbox by an e-mail client. The lock file is usually an empty file with one notable exception. The lock file contains the hashed password if Encrypted Password file authentication is enabled on the server. The hashed password is compared to the hash value sent by client and the user is granted or denied access based on the comparison.

The mailbox will also contain a quota file if the authentication method is Active Directory integrated or local Windows account authentication. For these two methods, the quota file is created when the mailbox is created. If Encrypted Password file authentication is the authentication method, the quota file must be created by using the command-line tool Winpop. The security identifier (SID) for the account is contained in the quota file and file ownership of all messages is assigned to the SID.

Message Files

The message files are the last item of the organizational structure. All e-mail message files are created using a naming convention with an .eml extension appended to identify the file as a message. Because the volume of messages delivered to the POP3 service can be large, a naming convention was implemented that allows for 10,000 messages per millisecond. The naming convention names each e-mail message by using a timestamp consisting of the year, month, day, hour, minute, second, and millisecond plus a 4-digit counter. Using the message file format, message files appear as P3*##..##*.eml, where ##..## is a string of 26 digits derived by using the naming convention.

Authenticating Clients

The authentication module in the POP3 service is the interface to the authentication methods. The authentication module interacts with an abstraction referred to as an authentication database. The authentication process might refer to a file in the mailbox directory for authentication rather than query a database. The available choices for authentication method are:

• Active Directory integrated authentication

• Local Windows accounts authentication

• Encrypted Password file authentication

Paths to Authentication

The three possible paths to authentication are plaintext, NTLM, and authenticated POP (APOP). The plaintext authentication consists of the following sequence:

1. Client sends USER mailbox.

2. Server send +OK.

3. Client sends PASS password.

4. Server send +OK.

The NTLM sequence consists of the client sending an AUTH command, such as AUTH NTLM or AUTH APOP.

If the client sends the AUTH command with one of the authentication methods as an argument, the response and subsequent data are base-64 encoded to obscure the conversation. The client-server sequence still happens as described in RFC 1939, when AUTH is used but the commands and the responses must be converted to and from base64 encoding.

The ensuing discussion of authentication necessitates some mention of passwords being transmitted in the clear. NTLM requires the use of encrypted conversations during authentication. If NTLM is enabled, the plaintext transmission of passwords is not allowed. If the client sends the AUTH command, the server will respond with a listing of the accepted authentication mechanisms, APOP and NTLM. NTLM authentication is a challenge/response mechanism supported by the POP3 service. When the POP3 client connects to the server with the AUTH NTLM command, the server sends a random string of bytes (challenge) to the client, which the client encrypts with a hash of the user password. The client then sends the encrypted challenge back to the server where the response is decrypted with the password hash stored on the server. If the server is able to derive the original challenge from the client response, then the client is successfully authenticated.

APOP authentication is a challenge/response process used with POP3 and Internet Message Access Protocol 4 (IMAP4) servers. When a client connects to the mail server, the server appends an ASCII character string to the server greeting message. The client uses the string and the user password to create a hash value that is transmitted to the server, where it is compared to the value in the encrypted password file. When APOP is enabled, Encrypted Password file authentication uses the MD5 hashing algorithm in conjunction with CRAM, referred to as MD5-CRAM.

Authentication Methods

Active Directory integrated authentication is an option if the POP3 server is installed in an Active Directory domain on a domain controller or member server. Active Directory integrated authentication supports both plaintext authentication and NTLM authentication. The authentication store can be an Active Directory database or a global catalog derived from an Active Directory database.

Local Windows accounts authentication is an option when the POP3 server is not a member of an Active Directory domain and user accounts are created and maintained on the local server. Local Windows authentication supports both plaintext and NTLM authentication. When local accounts are created for POP3 user accounts, the authentication store is the local SAM database.

Encrypted Password file authentication is an option when the POP3 server is not a member of an Active Directory domain and user accounts are not created on the local server. A hash of the password is created using the Message Digest 5 (MD5) hashing algorithm and saved in the lock file in the mailbox when Encrypted Password file authentication is chosen as an authentication method. During authentication, the client sends a hash of the user password which is compared to the hashed password stored in the lock file. This type of authentication is called a Challenge Response Authentication Mechanism (CRAM). If the hashed passwords match, the authentication of the user is successful. Encrypted Password file authentication supports both plaintext and APOP authentication.

POP3 Service and Authentication Module

The authentication process shown in the figure Architecture of POP3 Service and Authentication Module is a conceptual representation of the authentication.

Note

• MD5 is a hashing algorithm, based on its predecessors, MD2 and MD4. CRAM is a challenge-response authentication mechanism, based on the hashing of a password known only to the server and the user. When using the MD5-CRAM mechanism, a client transmits a digest of a password in response to a challenge from the server. The hashed password is sent across the network to be used in the authentication of a user.

Requesting E-mail Delivery

In the figure POP3 Service and Mail Store, the Mail Storage Access API provides an abstraction to the mail store and is shown as an interface to the mail store.

POP3 Service and Mail Store

If the client has successfully authenticated with the server, then the session progresses to the Transaction state. Other than the NOOP command, all of the commands sent by the client in the Transaction state require the POP3 service to access the mail store. The POP3 service reads from and writes to the mail store by means of the Mail Storage Access API.

The Mail Storage Access API creates an abstraction to the storage environment. This abstraction offers a consistent interface to the mail store and allows other storage possibilities in future releases. The Mail Storage Access API is called by other modules in the POP3 service, including the SMTP delivery service for POP3 and the POP3 Server Administrator.

When the client successfully authenticates with the service, the POP3 service modifies the lock file in the users mailbox directory to prevent another session from opening the same mailbox. The mailbox “lock” file is named “lock” and this file is created when the mailbox is created. When the mailbox is locked, the file name is reversed to “kcol.” The mailbox lock does not interfere with the mail delivery service as it delivers messages.

Delivering Messages

In the figure POP3 Service and Mail Delivery, the delivery of a message from the Internet to the POP3 mail store is illustrated. The message is shown passing through the SMTP delivery service for POP3 to the mail store, where it can be downloaded using the POP3 service.

POP3 Service and Mail Delivery Module

The SMTP delivery service for POP3 delivers messages to the individual mailboxes in the mail store. The delivery service replaces the default SMTP mail delivery module. When new mail arrives, the delivery service is notified by the SMTP service that the SMTP service has put messages in the SMTP Queue folder. The delivery service is an event sink that is triggered by the arrival of new mail. The SMTP delivery service for POP3 uses the same Mail Storage Access API to write the message files as the POP3 service uses to retrieve messages from the message store. If a message is delivered to a mailbox that is currently in use, the message is not available during this session and must be downloaded during a subsequent session.

The mail is delivered to the mailbox after it is retrieved from the Queue folder. A message sent to multiple recipients in a POP3 domain will be retrieved from the Queue folder as multiple messages, one for each recipient. The POP3 mail store does not implement single-instance message store, therefore each mailbox receives a copy of the message. Each message file is named using the naming convention described in the section on the physical structure of the POP3 service.

If quotas are in place and the user has exceeded the disk space quota, the message is returned to the sender if the Deny disk space once the quota has been met option is enabled. If the nondelivery report (NDR) cannot be sent to the original sender, the message is left in the Badmail folder.

Administering the Server, Domain, and Mailbox

The POP3 Server Administrator provides control over the POP3 service, domains, and mailboxes. Through the POP3 Server Administrator, all settings for the server, domain, and mailbox are available. The POP3 Server Administrator stores settings for the authentication method, socket and thread pool, and port number in the registry of the server. The architecture diagram does not depict the registry but these settings are registry entries.

In the figure POP3 Service and Server Administrator, the interaction with other components of the POP3 service is shown. The Server Administrator uses the Mail Storage Access API to make changes to mail store, such as creating new domains and users. The Server Administrator also creates and modifies settings in the IIS metabase.

POP3 Service and Server Administrator

Creating a Domain

The POP3 Server Administrator uses the Mail Storage Access API to create, modify, or delete domains in the mail store. When a new domain is created, the server administrator creates a directory entry for the domain under the mail root. There are three steps performed for the domain creation:

• Create a directory for the domain.

• Set the permissions on the directory.

• Add the domain name as an SMTP domain listing in the IIS metabase.

The new domain name is added as an SMTP property for SMTP in the IIS metabase. When a new domain is created to be used by multiple POP3 servers, the server administrator creates a directory entry for the domain and adds the domain name to the IIS metabase on the server. Subsequent installation of other servers accessing the same store will only add the domain name to the IIS metabase on that server.

Deleting a Domain

When a domain is deleted, the directory entry is deleted from the directory and the domain name is removed from the metabase. The deletion of a POP3 domain in an environment with multiple servers has some caveats that are worth noting. The first installation of a domain creates the mail store and adds the domain name to the metabase; the first deletion of a domain removes the mail store and deletes the domain name from the metabase. The domain name must be deleted from the metabase on other servers by deleting the domain on those servers.

Creating a Mailbox

The POP3 Server Administrator uses the Mail Storage Access API to create, modify, or delete mailboxes in the mail store. When a new mailbox is created, a directory is created under the domain for the mailbox. The following actions occur when the mailbox is created:

• Create the mailbox in a directory in the POP3 domain.

• Set permissions on the mailbox. When the mailbox is created, only local and domain administrators and the local network service have permissions to read from and write to the mailbox.

• Create an associated account. If the service is using Active Directory integrated or local Windows account authentication, an associated account should be created. No associated account is created for encrypted password file authentication.

• Add account to groups, if necessary. If the local Windows account authentication method is chosen, the user created for the associated account will be added to the “POP3 Users” group, which has no rights to log on locally to the server. If Active Directory integrated authentication is chosen, the user created for the associated account will have typical Active Directory domain user rights.

Deleting a Mailbox

When an existing mailbox is deleted, the mailbox and its contents are deleted from the server. The POP3 Server Administrator deletes the associated account in Active Directory or the SAM database only if the option to delete the associated account was specified. Otherwise, the administrator will be prompted about the deletion of an associated account. If Encrypted Password authentication is being used, no associated account was created.

Locking or Unlocking Domain Mailboxes

The POP3 Server Administrator can lock or unlock individual mailboxes or all mailboxes in a domain. When a mailbox is created, a lock file is created in the mailbox directory. The POP3 Server Administrator locks the mailbox by changing the name of the “lock” file from “lock” to “kcol.” The POP3 service uses the same functionality to lock a mailbox when a session is underway to prevent simultaneous access to a mailbox.

The POP3 Server Administrator uses the Mail Storage API to access the mail store. The POP3 Server Administrator configures the IIS and SMTP service components through the IIS metabase.

Network Ports Used by POP3

By default, the POP3 service listens on the well-known TCP port 110 for incoming connections from e-mail clients. There is no UDP port for the POP3 service. The administrator of the POP3 service can specify a different TCP port using the administration tools, provided that the new port number is not already reserved for another protocol.

Port Assignments for POP3

Service Name	UDP	TCP
POP3 Service	None	110 or an unassigned port chosen by the administrator.

Related Information

The following resources contain additional information that is relevant to this section.

• RFC 1939, “Post Office Protocol -Version 3” in the IETF RFC Database

• RFC 2821, “Simple Mail Transfer Protocol” in the IETF RFC Database