Skip Headers
Oracle® Mail Administrator's Guide
10g Release 1 (10.1.1)

Part Number B14491-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

3 Oracle Mail Servers

This chapter discusses the different servers of the Oracle Mail system.

A typical installation of Oracle Mail will have either POP or IMAP servers running but not both. It is good practice, too, to have two instances of each server running for availability. Note, however, an instance of a server consumes resources, such as memory, processing, and database connections. Not all of the processes need to be running, either, as would be the case if an installation has only clients that access stored messages using IMAP servers. In this case, POP servers would be unnecessary and could be turned off and disabled.

In most cases, set all parameter values at the target level. Notable exceptions are Housekeeper and SMTP Outbound.

This chapter includes the following topics:

Oracle Collaboration Suite Database

Oracle Mail uses the Oracle Collaboration Suite 10g Database (Oracle Collaboration Suite Database) to store user folders and messages. The Oracle Collaboration Suite Database can be configured to store folders and messages for users in different domains. Messages destined for many accounts are stored only once, and links to the messages are set for all recipients. Single Oracle Collaboration Suite Databases can store mail for one domain or several different domains, while a large domain can be supported by multiple Oracle Collaboration Suite Databases.

Users can have one or more folders. These folders can be private, public, or shared. Private folders are visible only to the owner. Public folders are visible to all users in the owner's domain. Shared folders are visible to specified users and specified distribution lists.

Modifying Oracle Collaboration Suite Database Connection Parameters

The Oracle Collaboration Suite Database parameters are used by the Oracle Mail servers to connect to the Oracle Collaboration Suite Database.

To modify Oracle Collaboration Suite Database default parameters:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Click a server in the Name column, such as IMAP Server, POP Server, or List Server.

  5. In the Target section, click Collaboration Suite Database Connection Parameters.

  6. Select the Oracle Collaboration Suite Database for which you want to make changes.

  7. Modify the parameters listed in Table 3-1 you want to change.

    Table 3-1 Oracle Collaboration Suite Database Connection Parameters

    Parameter Option Description

    Timeout (seconds)

    Enter a non-negative number

    Number of seconds before increasing the pool... The default value is 3600.

    Increment

    Enter a non-negative number

    Number of Oracle Collaboration Suite Database connections to be added to the connection pool. The default value is 1.

    Minimum

    Enter a non-negative number

    Minimum number of Oracle Collaboration Suite Database connections in the connection pool. The default value is 1.

    Maximum

    Enter a non-negative number

    Maximum number of Oracle Collaboration Suite Database connections in the connection pool. The default value is 10.

    Alternate Connect String

    String

    Depending upon which server's Oracle Collaboration Suite Database connection parameters are being modified, the alternate connect string is used by that server to connect to the mailstore chosen in step 6.

    The Oracle Collaboration Suite Databases shown on this page are the ones that are associated with this server or its instances on the Default Settings and Instance Settings pages.

    See Also: "Modifying Server Instance Default Parameter Settings" or "Modifying Parameter Settings for a Specific Server Instance" for information about associating specific Oracle Mail servers with Oracle Collaboration Suite Databases


  8. Click Apply.

Managing Oracle Mail Servers and Instances

This section discusses how to start, stop, restart, refresh, and modify servers and instances using the Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite.

Starting an Oracle Mail server starts all the instances constituting that server type, such as IMAP and POP.

Stopping an Oracle Mail server sends a command to the server instances to shut down. Whenever instances are created or certain parameter values are changed, the server must be stopped prior to any such action.

System maintenance is another reason an administrator should stop a server, such as upgrading the server hardware or software. The Oracle Mail server instances cannot be running while this kind of upgrade is being performed.

Restarting an Oracle Mail server first stops the server and then restarts it. An administrator can restart a server after particular parameters have been modified in order to apply the changes.

Refreshing an Oracle Mail server notifies running instances to reread the configuration. Changed configuration values take effect but only for certain parameters, such as Process Log Level. Current instances do not stop. For example, the IMAP log level can be changed, the IMAP server refreshed, and the new log level will take effect without any current user sessions getting disconnected.

This section includes the following topics:

Log Files

Oracle Mail server logs files are located in the $ORACLE_HOME/oes/log/server_type directory. For example, List Server logs are found in the $ORACLE_HOME/oes/log/list directory. Each running server instance creates a log directory for itself when it starts and then writes to a log file in that directory.

For example, if there is a List Server instance running on a UNIX platform, and the operating system process ID for the process is 12345, the log file for the process will be $ORACLE_HOME/oes/log/list/12345/12345.log.

The maximum size to which a log file can grow is configured by the Maximum Log Size parameter for a particular server. If a log file reaches the maximum size, it is renamed and a new log file is created. The old file is renamed by appending a number to the file name, such as 12345.log.000.

The renaming process cascades to older files. The names of older files are changed by increasing the value of the appended number. Example 3-1 shows a list of the log files in the log directory of the SMTP Outbound server.

Example 3-1 List of SMTP Outbound Server Log Files

% cd $ORACLE_HOME/oes/log/um_system/smtp_out/13067
% ls
13067.log      13067.log.002  13067.log.005  13067.log.008
13067.log.000  13067.log.003  13067.log.006  13067.log.009
13067.log.001  13067.log.004  13067.log.007

In the preceding example, log file renaming has occurred many times. The server instance is currently writing to 13067.log, the next most recent log file is named 13067.log.000, and the oldest log information is in the file named 13067.log.009.

The number of old log files to keep is configured by setting the Maximum Number of Log Files server parameter. Once the maximum number of log files is reached due to log file renaming, the oldest file is deleted.

In Example 3-1, if the Maximum Number of Log Files parameter is set to 10, and the size of the file named 13067.log grows to the maximum log size, the file named 13067.log.009 will be deleted, all remaining files will have their names changed, and a new 13067.log file will be created.

Log files for Oracle Mail servers are also found in the $ORACLE_HOME/opmn/logs directory. These log files contain debug and error output from the servers. Usually, it is not necessary to look at these files but they can be useful when investigating problems with servers.

Example 3-2 shows where the administrator changes to the opmn log directory and lists the Oracle Mail server log files.

Example 3-2 Oracle Mail Server Log Files Listed in the opmn Log Directory

% cd $ORACLE_HOME/opmn/logs
% ls -1 email*
bash-2.05$ ls -1 email*
email~email_housekeeper~111669348732673252~1
email~email_imap~11166933915459529~1
email~email_imap~111669641725581757~1
email~email_listserver~111669349628087514~1
email~email_smtp_in~111669352320380482~1
email~email_smtp_in~111669739031461932~1
email~email_smtp_out~111669352925661397~1
email~email_smtp_out~111670781734121085~1
email~email_virus_scrubber~111669353532515101~1

Example 3-3 shows the debug output available in these files.

Example 3-3 Debug Output

% tail -18 email~email_smtp_in~111669352320380482~1
--------
05/06/25 13:44:40 Start process
--------
successfully added instance 111669352320380482[0,1000,0,1000]
good; added service  [ESSMI]
nslisten succeeded!
good; added registrar  [(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=OCS_RGMUM300.appserver.acme.com)))]
good; mapped instance to all registrars
good; mapped service 0 to all registrars
complete addr is (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=45963))(PRESENTATION=ESSMI)(SESSION=NS))
good; added handler  [111669352320380482]
good; mapped handler 0 to all registrars
nsgrRegister succeeded!
INIT    with 0 registrars.
SUCCESS with 0 registrars.
WAITEV  with 0 registrars.
WAITEVP with 1 registrars.
FAILURE with 0 registrars.

Enabling and Disabling Servers

A server must be enabled before it can be started. Disabling a server prevents it from being started.

To enable or disable a server:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select a server to enable or disable.

  5. Click Enable or Disable.

Note:

Disabling a server that is currently running will first stop the server, then disable it.

See Also:

for information about enabling and disabling servers from the command line

Starting, Stopping, Restarting, or Refreshing All Server Instances

To start, stop, restart, or refresh all instances of a particular server:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select a server to start, stop, or refresh.

  5. Click Start, Stop, Restart, or Refresh.

    Click Restart to apply any changes made to any server instance parameters. Restart shuts down all instances of the selected server before starting them up again. This will result in a brief interruption of e-mail service.

    Click Refresh to apply changes made to log levels or debug flags. Refresh does not shut down instances of the server and will not interrupt any service.

    Note:

    The refresh icon located on this page refreshes the information on this page, not any servers.

See Also:

"Starting All Instances of an Oracle Mail Server" for information about starting all server instances from the command line

Creating a Server Instance

To create a server instance:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select the server for which the new instance is to be created.

  5. Click Stop to bring down the server.

  6. Click the server in the Name column to display the page for that server.

  7. Click Create. This creates a new server instance that inherits the default parameters.

    Optionally, click Create Like to create a new server instance with the same parameters as an existing, previously selected server instance.

  8. Click the newly created instance to modify the parameter values.

  9. Click Apply when finished.

  10. Click Clear Instance Settings to clear parameter settings for all process instances listed.

  11. Return to the Mail Application page.

  12. Select the server for which the new instance was created.

  13. Click Start to bring up the server.

See Also:

Deleting a Server Instance

Caution:

Deleting an Oracle Mail server instance may disable some or all e-mail processes.

To delete a server instance:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select the server from which the instance is to be deleted.

  5. Click Stop to bring down the server.

  6. Click the server in the Name column to display the page for that server.

  7. Select the server instance you want to delete.

  8. Click Delete.

Modifying Server Instance Default Parameter Settings

All new server instances that are created inherit the default parameter values for that server type, unless the instance is created using the Create Like button. The parameters, both default and replicated, can later be modified for specific server instances.

Notes:

  • In most cases, administrators should modify parameters only at the target level to reduce the chances of creating conflicts between two instances of the same server. Two notable exceptions to this are the Housekeeper server and the SMTP Outbound server.

  • Servers must be restarted or refreshed whenever parameters are modified.

See Also:

To modify default server instance parameter settings:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Click a server in the Name column, such as IMAP Server, POP Server, or List Server to display the page for that server.

  5. Click Default Settings in the Target section.

  6. Modify the parameters you want to change or click Revert to reset the parameters to their default values.

    Click Cancel to cancel any changes and return you back to the server page.

  7. Click Apply to apply changes.

  8. Restart the server to apply any changes prior to creating any new server instances.

Modifying Parameter Settings for a Specific Server Instance

Notes:

  • Servers must be restarted whenever instance parameters are modified in order for the changes to be applied.

  • Whenever a setting is cleared at the instance level, the corresponding value from the default parameter settings page is used. This inheritance occurs all servers and Oracle WebMail.

To modify parameters for a specific server instance:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Click a server in the Name column, such as IMAP Server, POP Server, or List Server to display the page for that server.

  5. Click the server instance you want to modify.

  6. Modify the parameters you want to change or click Revert to reset the parameters to their default values.

    Click Cancel to cancel any changes and return you back to the server page.

  7. Click Apply to apply changes.

  8. Restart the server to apply any changes.

Protocol Servers

The framework maintains a pool of worker threads that handle the work for the clients. In addition, a pool of database connections are shared across client connections. Incoming client requests have worker threads assigned to them. Worker threads read client commands, obtain database connections, and carry out operations. Once the database connections are released back to the pool, the threads return to the worker thread pool.

A system can contain multiple mail stores, and the IMAP and POP servers can be configured to create database connection pools to more than one mail store. Administrators use the IMAP and POP server parameters to control connection pool sizes.

This section includes the following topics:

IMAP and POP Servers

The Internet Message Access Protocol IMAP (the current version is IMAP4) provides functionality to manipulate mail messages and mail folders stored on the server and to enable an off-line client to re-synchronize with the server. IMAP also has primitives enabling optimization of online performance, especially for large MIME messages.

The Post Office Protocol POP (the current version is POP3) provides mail manipulation services for smaller Internet nodes where it can be impractical to maintain a message transport system or undesirable to keep an Internet connection open for long periods of time. Messages are temporarily stored on the server until they are downloaded to a client machine.

Note:

Either the IMAP server or the POP server will be enabled in a given installation. Depending upon which server is used in an installation, disable the unused server.

This section includes the following topics:

IMAP and POP Server Architecture

The IMAP and POP servers obtain the benefits of multi-threading, database connection sharing, and load balancing by using the scalable protocol server programming framework. These benefits enable the servers to support thousands of concurrent user connections while using very few system resources.

The framework maintains a pool of worker threads that handle the work for the clients. In addition, a pool of database connections are shared across client connections. Incoming client requests have worker threads assigned to them. Worker threads read client commands, obtain database connections, and carry out operations. Once the database connections are released back to the pool, the threads return to the worker thread pool.

A system can contain multiple mail stores, and the IMAP and POP servers can be configured to create database connection pools to more than one mail store. Administrators use the IMAP and POP server parameters to control connection pool sizes.

Many operating systems limit the number of file descriptors and sockets that a single instance can open. These limits can make it necessary to run more than one instance of an IMAP or POP server, in which case the listener distributes the load between them. Administrators must verify the correctness of the operating system parameter controlling the file descriptors for such instances.

See Also:

Oracle Collaboration Suite Installation Guide for Solaris Operating System for more information about operating system parameters

IMAP and POP Session Data Flow

As a user connects, either through various clients, such as Microsoft Outlook or Mozilla, or the Oracle WebMail client, it is important to understand the connection flow and the components the clients are accessing during login and during an individual session.

All IMAP- and POP-compliant clients are able to access the Oracle Mail server. These clients must be directly installed on the end-user client's system and is configured by that user.

The access method flow is described, as follows, and shown in Figure 3-1:

  1. The client launches an application, such as Microsoft Exchange or Mozilla. The client must be configured to connect to the system where IMAP and POP are listening.

  2. The user is prompted to enter in a username and password.

  3. Authentication of the login information is checked against the Oracle Collaboration Suite Infrastructure through the IMAP server connection for validation. A connection is opened from the LDAP connection pool of the IMAP server. Once authentication is validated, the LDAP connection is released back to the original connection pool.

  4. The user IMAP connection is passed to the database connection pool for access to the user e-mail account.

  5. Once connected, a download of the user's INBOX begins. It will also accumulate any new messages and post them to the INBOX for sorting.

  6. Once the INBOX download is complete, the client releases the database connection back to the database connection pool, but maintains an authenticated cached connection to the IMAP instance.

  7. Now, when there is a call to the database, such as when a user opens a message or opens a folder, a new connection to the database is established to respond to the request. Again, once the request is satisfied, the database connection is released.

Figure 3-1 IMAP and POP Data Flow

Description of Figure 3-1 follows
Description of "Figure 3-1 IMAP and POP Data Flow"

Oracle WebMail Client Session Data Flow

The Oracle WebMail client runs on the Oracle Collaboration Suite Applications Tier. It is not necessary for the user to download any information, except for a cookie to the local client. Besides entering a URL in a Web browser, there is no local configuration necessary. However, the authentication method is similar to that of other clients, with the exception that the Oracle WebMail client caches the user preferences. The access method is through OJMA and is not, by default, using the IMAP server. IMAP can be configured to use IMAP through the oc4j.properties file under the $ORACLE_HOME/j2ee/OC4J_OCSClient/config directory.

The access method flow is described, as follows, and shown in Figure 3-2:

  1. The client launches a browser and enters a given URL. This URL connects to the application tier where the Oracle WebMail client is configured.

  2. The user is prompted to enter a username and password. Once committed, it calls the ESDS API.

  3. The ESDS API uses the authentication information to check against the Oracle Collaboration Suite Infrastructure for validation. The connection is opened through the ESDS LDAP connection pool. Once authentication is validated, the LDAP connection is closed.

  4. Once authenticated, the connection is passed to the OJMA connection pool for direct access to the user e-mail account.

  5. Once connected, a display of the user's Inbox begins. It will also accumulate any new messages and post them to the Inbox for sorting.

  6. Once the INBOX download is complete, the database connection is released back to the database connection pool, but maintained as an authenticated user by OJMA.

  7. Now, when there is a call to the database, such as when a user opens a message or opens a folder, a connection from the pool is opened by OJMA and the request is satisfied. Again, once the request is satisfied, the database connection is released.

Figure 3-2 Oracle WebMail Client Data Flow

Description of Figure 3-2 follows
Description of "Figure 3-2 Oracle WebMail Client Data Flow"

IMAP and POP Server Instance Parameters

See Also:

"Oracle Mail IMAP Server" and "Oracle Mail POP Server" for detailed information about IMAP and POP server instance parameters

Managing IMAP and POP Servers

See Also:

"Managing Oracle Mail Servers and Instances" for instructions on creating, deleting, and modifying server instances

SMTP Server

The Simple Mail Transfer Protocol (SMTP) enables e-mail messages to be sent between servers, and is used by most Internet e-mail systems. Mail clients use SMTP to send messages to a mail server, and use either POP or IMAP to retrieve messages.

The SMTP server handles all inbound and outbound mail, implements the SMTP protocol, and interacts with the domain name server (DNS) and the Oracle Internet Directory server for information about hosts and users.

The SMTP server is also responsible for delivering e-mail messages to archive servers based on configured archive policies.

See Also:

"Oracle Mail Archive Policies" for more information about archive policies

This section includes the following topics:

Various SMTP Configurations

The flexible architecture of Oracle Mail enables users to set up a single or multitier configuration appropriate to a site's needs.

This section includes the following topics:

Single Node Setup

A single node setup has one Oracle Collaboration Suite Database and one SMTP server running on the same host, supporting a small numbers of users.

Single Oracle Collaboration Suite Database Setup

A single Oracle Collaboration Suite Database setup divides two servers into two tiers:

  • The tier where the Oracle Collaboration Suite Database resides

  • The Oracle Collaboration Suite Applications Tier where SMTP and other protocol servers reside

This configuration provides fault tolerance and the flexibility to run multiple SMTP servers with distributed loads by running the servers behind a network director. Alternatively, it can have multiple MX records for the domain.

Multiple Oracle Collaboration Suite Database Setup

A multiple Oracle Collaboration Suite Database is a scaled version of a single Oracle Collaboration Suite Database setup to support a large user base. The multiple database setup consists of a set of hosts each running an Oracle Collaboration Suite Database, and the Applications Tier that includes a set of hosts running the SMTP server and other protocol servers. Each SMTP Inbound server can accept and deliver mail to multiple databases. SMTP Outbound performs queue processing against a single database and delivers to multiple databases. It is possible to have one database just to receive the mail and the rest supporting the user base for added fault tolerance and reduced contention.

Each SMTP server serves only one Oracle Collaboration Suite Database and each Oracle Collaboration Suite Database must have an SMTP server. The Oracle Collaboration Suite Databases on the SMTP hosts are used as SMTP queues and do not contain users.

SMTP Message Flow

The SMTP Inbound server is responsible for handling the incoming SMTP connection. It receives incoming messages, queries the Oracle Internet Directory server to find and authenticate the addresses, rewrites addresses based on the rewriting rules, and applies anti-spam rules. If all the steps are successful, the SMTP message transfer agent (MTA) accepts the message and inserts it into the corresponding queue based on the destination address, as shown in Figure 3-3.

If the message recipient is a user outside of the Oracle Collaboration Suite system, the message is stored in the relay queue to await further processing. If the recipient is local, the message is stored in the local delivery queue. The Local Domains parameter contains the list of local domains used to determine whether an address is local. The local delivery module picks up the message later, applies the rules, and delivers it to the user's inbox.

If administrators do not want to process the messages immediately, they can be stored in the submission queue and marked as submitted or unprocessed. Messages created by the SDK applications are also placed in the submission queue and marked as submitted. Messages in the submission queue are picked up by the SMTP Outbound server.

For relay messages, the SMTP Outbound server queries the DNS server, applies any rules to the messages, and sends them out using SMTP. For submitted messages, processing by the address rewriting and DNS resolution module happens first. Subsequently, the SMTP Outbound server sends them to the local delivery queue or to the Internet, depending on whether the messages' recipients are local.

During address resolution, the server determines whether the message is addressed to a distribution list handled by the List Server. If so, the server places the message in the queue for the List Server, which then picks up the message, expands the distribution list, and delivers the message.

Messages for users on a different Oracle Collaboration Suite Database are placed in the relay queue. The outbound server picks up and delivers the messages to the SMTP Inbound server for the other Oracle Collaboration Suite Database.

If the recipient is determined to be local, the message is stored in the local delivery queue. To determine if an address is local, the Local Domains parameter is used. This parameter contains the list of domains that are considered local.

If the recipient is an outside user, either on another Oracle Collaboration Suite Database or on the Internet, the message is stored in the relay queue to await further processing by the SMTP Outbound server.

See Also:

"SMTP Address Rewriting Rules" and "List Server" for more information

The SMTP server is also responsible for delivering e-mail messages to archive servers based on configured archive policies. To enable archive delivery, set the Archive Processing parameter to Enabled in both SMTP Inbound and Outbound servers, in addition to the List Server. This parameter determines whether the servers will check all messages for archive eligibility.

Note:

The Archive Processing parameter must contain the same value for all the Applications Tiers to ensure that archive message processing is consistent. In addition to the Archive Processing parameter, also set Archive Queue Processing to Enabled for the SMTP Outbound server. This parameter allows the SMTP Outbound server to generate and deliver archive messages.

See Also:

"Oracle Mail Archive Policies" for more information about enabling the archive feature

Figure 3-3 SMTP Message Flow

Description of Figure 3-3 follows
Description of "Figure 3-3 SMTP Message Flow"

SMTP Inbound Server Architecture

The SMTP inbound server listens for client requests, processes incoming messages and either delivers them locally or places them into queues for further processing.

The Oracle Net listener listens for incoming client requests on the SMTP port (default 25) and transfers connections to the SMTP server. The SMTP server maintains three thread pools to perform its tasks:

  • Worker thread pool, through which it handles client requests

  • Oracle Internet Directory server connection pool, through which it performs user authentication and address resolution

  • Database connection pools to the configured Oracle Collaboration Suite Databases, through which it delivers local messages

    Note:

    If the recipient is an SMTP distribution list, the message is placed in the submission queue to be processed. The SMTP Outbound server expands SMTP distribution lists and performs delivery to expanded list.

Upon receipt of a connection request, a worker thread is picked up from the pool to handle the request and the following occurs:

  • Name resolution on the incoming message by using a connection from the Oracle Internet Directory pool is performed

  • If the SMTP server is enabled for archiving, determine whether archiving is needed for sender or recipient addresses. If message archiving is enabled, the message is placed in the archive queue for further processing.

    See Also:

    "Oracle Mail Archive Policies" for more information about enabling the archive feature
  • Anti-virus and anti-spam rules are applied

    See Also:

    "Oracle Mail Routing Control" for more information about these rewriting rules
  • Recipient rewriting rules are applied to the e-mail addresses to determine whether the message is to be delivered locally or sent to another Oracle Collaboration Suite Database, or out to the Internet

  • SMTP MTA accepts the message and inserts it into the corresponding queue based on the destination address

  • SMTP connection to the client is terminated for all but the local recipients and the worker thread continues to process the message and perform local delivery

SMTP Outbound Server Architecture

The STMP outbound queue processor processes messages in the submission, local, and relay queues. It has a main thread for each queue that periodically polls the database for messages in its queue. Whenever there are messages to process, a new thread is spawned to process the mail.

The outbound queue processor also maintains two other thread pools:

  • Oracle Internet Directory server connection pool, through which it performs address authentication. If SMTP_auth is turned on, this thread pool is also used for user authentication prior to sending out a message.

  • Database connection pool to the mail store, through which it delivers local messages

The size of all of these thread pools can be set through the Application Server Control Console for Collaboration Suite.

See Also:

"Modifying Parameter Settings for a Specific Server Instance" for more information about setting server parameters

When a thread is started to process a message from one of the queues, it picks up a database connection from the pool and gets connections from the Oracle Internet Directory pool as needed. After the mail is processed, the database and Oracle Internet Directory threads are returned to the pool.

Messages in the submission queue are treated as not yet processed, and so must go through the anti-virus and anti-spam rules and rewriting rules to determine their destination. After processing, the messages are either placed in the local delivery queue or in the relay queue.

If the recipient a user outside of Oracle Collaboration Suite, the message is stored in the relay queue to await further processing by the SMTP Outbound server. If the recipient is on an Oracle Collaboration Suite Database different from the database that was used to insert the incoming message, and if the SMTP Inbound server is configured to perform delivery to this database, the message is copied and delivered into this database using SQL*Net. If SMTP Inbound is not configured to deliver to the recipient's Oracle Collaboration Suite Database, the message is placed in the relay queue to await further processing by the SMTP Outbound server.

Messages in the local delivery queue are destined for a local mailbox, so the queue process or applies local rewriting and other rules, if any, and inserts the mail into the user's inbox in the database using a connection from the database pool.

Relay messages require further processing because their recipients are either on a different local message store or outside the e-mail system. Relay messages first go through the sender rewriting rules, then the system rules are invoked for event relay and external filter processing. If the system rule and external filter processing are successful, the DNS resolution takes place. The SMTP Outbound queue processor then sends them to another Oracle Collaboration Suite Database in the system or to the Internet using SMTP, depending on whether the messages' recipients are local or not.

If the delivery of an e-mail fails, the message is returned into the queue and delivery is retried after intervals defined by the minqueueage parameter. If the attempted re-deliveries are unsuccessful during the interval equal to the queuetimeout parameter, a delivery failure message is sent to the sender.

SMTP Address Rewriting Rules

The SMTP address rewriting rules enable you to check and correct an e-mail message's addresses before sending it to its final recipient destinations. Rules resolve a focused or internal format address into a mailer-host-user triplet that can be delivered.

Table 3-2 Mailer, Host, User Parameters

Parameter Description

Mailer

Specifies the Oracle Mail SMTP server daemons used for delivery.

Note: This is the only mailer available. Creating alternative mailers is not a feature of this application.

Host

Specifies either a fully qualified host name, such as hostname.acme.com, or a domain name, such as foo.com.

User

Specifies the recipient user name.


To execute and complete name resolution, the SMTP Inbound server parses each rule for every address in the message envelope during mail delivery.

This section includes the following topics:

Components of Rewriting Rules

Headers for the message and the envelope are distinctly different. The envelope headers are generated by that receiving e-mail application, rather than by the sender. Received: headers are the envelope headers, and relate only to the envelope From and envelope To fields.

The envelope From header is created from the MAIL FROM entry in the received message. For example, when a sending computer puts MAIL FROM: jsmith@acme.com in the message, the envelope From is jsmith@acme.com.

Similarly, the envelope To is derived from an incoming message line, such as RCPT TO: john.smith@acme.com. The information for envelope To and envelope From is stored in a different location from the header.

Mail is routed based solely on the envelope To data rather than on the message To: or From: headers supplied by the sender. These headers contain no significant envelope information and can misrepresent who sent the mail to whom, as is illustrated in Figure 3-4.

Figure 3-4 Message Header

Description of Figure 3-4 follows
Description of "Figure 3-4 Message Header"

A handshake between two SMTP systems executing transactions through port 25 involves a series of action dialogs for each message being delivered. These messages can be seen on the receiving or sending systems only by running in debug mode, as illustrated in the following example. The example illustrates why the routing of mail ignores the Message From and Message To headers, which can be faked.

Example of Original Headers

HELO acme.org
250 mail.rico.net Hello ernie.com [104.65.21.123], pleased to meet you
MAIL FROM: forged-address@acme.org
250 forged-address@acme.org... Sender ok
RCPT TO: john.smith@acme.org
250 john.smith@acme.org... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@moreover.com
To: (your address suppressed for stealth mailing and annoyance)
.
250 OAA08757 Message accepted for delivery

Resulting Headers as Seen by the Recipient

Received: from acme.org ([104.128.23.115]) by mail.rico.net (8.8.5) 
From: another-forged-address@moreover.org
To: (your address suppressed for stealth mailing and annoyance)

Notice that the only true data seen by this recipient is in the Received line, which was taken from the RCPT TO entry actually sent. The apparent sending addresses need not have any relationship to the physical facts. They are taken from the data of the envelope From, message From:, and message To: lines exactly as entered by the sender, with no necessary relationship to what is factual.

This example illustrates why the From, From:, and To: headers are not reliable in mail, because they can easily be forged.

Rule Execution Guidelines

Address rewriting rules are applied sequentially, beginning with rule 1. All rules are applied, unless a result starts with $@, which immediately stops rule execution and ignores any remaining rules. If a rule has a syntax error or cannot be executed, it is ignored.

A rule is applied to its own output in a loop until the application of the rule does not yield anymore changes in the result. The next rule in the sequence is then applied. After all the rules have been executed, an Oracle Internet Directory resolution is performed on the result. If the Oracle Internet Directory resolution returns a changed address due to an alias, for example the address rewriting rules are applied to the changed address, and the Oracle Internet Directory resolution is performed again. When the Oracle Internet Directory resolution rule does not yield any more changes, the rule execution process is done.

Oracle Mail Rewriting Rules

To understand rewriting rules, you must understand their components: a left hand side (LHS) and a right hand side (RHS) as explained in Table 3-3, used in this format:

Pattern (LHS),Result (RHS) [,Description]

where:

Table 3-3 Rewriting Rule Components

Format Description

Pattern (LHS)

Specifies the pattern to be changed

Result (RHS)

Specifies that whenever the Pattern (LHS) is seen, it is changed with this result.

Description

Specifies the administrator's rule notation, and is not used in address name resolution. Anything after the last comma does not require quotes.

Comma (,)

Separates the LHS, RHS, and Description. No spaces are allowed between the commas, nor before the first comma.


When the Pattern (LHS) is compared against the address and finds a match, the Result (RHS) replaces that match in the address. The comparison is not case-sensitive. If no match is found, then this rule is skipped and the next rule is applied. A rule can be applied to an address resulting from applying a previous rule.

Tokens and Matching

When processing an address for rewriting by a rule, the SMTP daemon first separates the address into parts called tokens and stores them into a buffer called the workspace.

A rule's Pattern (LHS) is also divided into tokens, which are then compared to the tokens in the workspace. If the two sets of tokens are identical, it is a match, and the result of the left hand side comparison is true.

Operators for Rewriting Rules

If rules always had to match addresses exactly, too many rules would be required and would render their usage unproductive. Instead, operators such as wild cards can also be used to match arbitrary text in the workspace. To make the entire Pattern (LHS) match, wildcard operators match as little as possible.

The following operators are used as wildcards or token identifiers:

  • $* = zero or more tokens, and prefers zero, or the fewest possible, to satisfy a Pattern (LHS) match

    Figure 3-5 Rewriting Rule Example

    Description of Figure 3-5 follows
    Description of "Figure 3-5 Rewriting Rule Example"

    For example:

    fred.jones resolved by the Pattern (LHS) rule 
    Result (RHS) rule = fred.jones@uuhost
    
    
  • $+ = one or more tokens, and prefers one, or the fewest possible, to satisfy an Pattern (LHS) match

    To illustrate, consider passing the address john.jones@home.ORG to this Pattern (LHS):

    Figure 3-6 Changing Uppercase to Lowercase

    Description of Figure 3-6 follows
    Description of "Figure 3-6 Changing Uppercase to Lowercase"

    For example:

    john.jones@home.ORG resolved by the Pattern (LHS) rule,

    Result (RHS)= john.jones@home.org
    $* (matches zero or more) = john.jones
    @ matches exactly 
    $+ (matches one or more) = home
    
    
  • $- = exactly one token

    john rewritten by rhs $- = ->john

    If the result was john@uuhost, then the rule would not match.

RHS Operator Descriptions

  • $1,$2 identifies Pattern (LHS) tokens to be passed over into the Result (RHS). These are copied by position from the Result (RHS) location.

  • lhs $*.$* where rhs $1.$2

  • $: Indicates that the rule should be applied only once

  • rhs john rewritten by $:$1 = john

  • $@: Exactly none. Rules are not applied beyond this point if the $@ operator is reached during the rewriting rule processing.

  • $!: Reject: A DSN will be sent will be sent if outbound SMTP is rewriting

  • $%: Discard: The address is discarded. No DSN is sent if the SMTP Outbound server is rewriting.

Creating an Oracle Mail Address Rewriting Rule

Oracle Mail uses two types of address rewriting rules:

  • Sender rewriting rules: Applies to senders, only, of messages that are relayed out by SMTP Outbound

  • Recipient rewriting rules: Apply to all incoming and outgoing recipient addresses

Rules can be written using the Application Server Control Console for Collaboration Suite and are executed in the order they are entered.

Examples of Rewriting Rules

The following example takes the From: (sender) and the To: (recipient) addresses and rewrites them using the rewriting rules.

  • Sender Rewriting Rules

    $*@$+.com,$1@uuhost.com, "This changes john.doe@foo.com to john.doe@uuhost.com"
    
    

    Rule:

    1. Match anything before the @ sign and take the one token after the @ sign with the .com at the end and change it.

    2. Keep the user name and pass it to the RHS through $1, which is in direct order or the first token from the LHS, john.doe and pass the @ sign as is, but change the $2 token (second token) and change it to uuhost.com.

      The receiving SMTP daemon accepts this message, and accepts john.doe@uuhost.com as the sender of the message. It is important to remember that the header information is never changed from its original entries.

  • Recipient Rewriting Rules

    $*.$*@uuhost,$1.$2@foo.com, "This changes fred.jones@uuhost to fred.jones@foo.com"
    
    

    Rule:

    1. Capture both the first name and the last name of any address that has uuhost after the @ sign.

    2. Bring those tokens over as $1 and $2 respectively, and keep a period (.) between them.

    3. After the @ sign, replace uuhost with foo.com.

  • Rewriting an E-mail Address

    The following example shows how to rewrite an e-mail address using fred.jones@uuhost. The address points to uuhost which is a Unix to Unix copy (UUCP) system name. The message is sent using the UUCP software which requires the address form of uuhost!username, and that the current address be rewritten for UUCP. Consider the following example:

    $*@uuhost,uuhost!$1,"Changing from to UUCP address"
    
    

    Using the following rewriting rule, you can change this address to a more compatible Internet address such as fred.jones@foo.com:

    Figure 3-7 Message Flow through Rewriting Rules

    Description of Figure 3-7 follows
    Description of "Figure 3-7 Message Flow through Rewriting Rules"

    where:

    $* token in Pattern (LHS) resolves as anything after the exclamation point (!).

    $* = fred.jones.

    The comma (,) is the separator between the LHS, RHS, and Description.

    The $1 or first token in LHS string ($*) moves to the RHS is as.

    Message headers are not rewritten during SMTP address name resolution. The address is parsed and rewritten by the delivery daemon rewriting rules, and passed as a logical address to the receiving daemon, which then parses and resolves it.

SMTP Server Parameters

See Also:

Managing SMTP Servers

If message archiving is enabled on your Oracle Mail installation, create a server instance of the SMTP Outbound server that is dedicated to the handling of archived messages.

See Also:

SMTP Routing Control

See Also:

"Anti-Spam" for more information about routing control

Housekeeper Server

The Housekeeper server is a background process that works inside the Oracle Collaboration Suite Database and performs periodic tasks, such as garbage collection, which cleans up deleted message bodies. Additional tasks include performing Oracle Text index synchronization and optimization for enabling message body search, and moving message bodies to tertiary storage tablespaces.

During Oracle Mail installation, a Housekeeper instance is created by default to perform basic garbage collection. Once the server process finishes its assigned task, it sleeps for a configured amount of time before waking up to restart the tasks.

The Housekeeper server can also be configured to start and stop running certain tasks dynamically from the command line, enabling the administrator to control the exact time when certain tasks are started.

See Also:

"Dynamically Starting and Stopping Housekeeper Tasks" for instructions on dynamically starting and stopping Housekeeper tasks from the command line

The Housekeeper server consumes data produced by other Oracle Mail servers. For example, the pruning garbage collection task processes all the messages produced by the IMAP expunge command and filters out those messages that are still referenced by users. Additionally, the collection task processes the rest of the pruned result and removes all message bodies. Housekeeper metric information enables administrators to track the progress of its tasks.

The Housekeeper process can also be configured to enable LogMiner-based mail recovery. Once this feature is enabled, vital information about all deleted messages is kept in the database, allowing these messages to be recovered at a later time.

Note:

Enabling LogMiner recovery may lead to Housekeeper process performance degradation.

The Housekeeper log files are located in two places: the Oracle Collaboration Suite Database and the Applications Tier. The log file on the Oracle Collaboration Suite Database contains information on the progress of housekeeping tasks; the log file on the Applications Tier contains information on the status of the process.

The Housekeeper server is designed to perform eight distinct and separate tasks:

This section includes the following topics:

Configuring Housekeeper Tasks

For the Housekeeper server to perform all eight of the aforementioned tasks, either eight separate instances of the Housekeeper server can be configured, or tasks can be combined. At a minimum, three separate instances must be configured in order to perform all eight tasks.

Regardless, Oracle recommends that for any size installation, three separate instances of the Housekeeper server be configured to perform the following three tasks:

  • Garbage Collection: Deleting an instance of a message or the message itself is an expensive operation for the database in terms of resource consumption. Therefore, for performance reasons, when you delete a message you actually tag the message to be permanently deleted later. The Housekeeper server, in the background, performs the cleanup of the Oracle Collaboration Suite Database.

    See Also:

    "Process Control Message Cleanup" for more information about additional Housekeeper tasks that can be combined with the garbage collection instance
  • Text Indexing: Indexing messages is the process of looking at each message in detail (message bodies, headers, and attachments) to facilitate searching and is another expensive operation for the database in terms of resource consumption. Therefore, for performance reasons, messages that need to be indexed are pre-indexed. The Housekeeper server, in the background, indexes the messages stored in the Oracle Collaboration Suite Database.

  • Tertiary Storage: Users often keep messages in their production Oracle Collaboration Suite Database for long periods of time. The Oracle Collaboration Suite Database has the concept of tertiary storage. This is a separate set of tablespaces designed to store these older messages. An administrator can configure these tablespaces on less expensive or slower disks because they will be accessed less often. The Housekeeper server, in the background, moves messages of a specified age to tablespaces in tertiary storage.

    See Also:

    "Tertiary Storage" for information about configuring a Housekeeper server instance for tertiary storage

This section includes the following topics:

Process Control Message Cleanup

As mentioned previously, a Housekeeper server instance configured for garbage collection is created by default upon installation of Oracle Mail. In addition to garbage collection, configure this instance to perform process control message cleanup.

Different Oracle Mail servers sometimes use advanced queuing to facilitate interprocess communication. The Housekeeper server can be configured to clean these messages, improving Oracle Mail performance.

Note:

This procedure combines the Process Control Message Cleanup operation mode with the Pruning and Collection tasks.

To enable process control message cleanup:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select the Housekeeper server and click Stop to bring down the server.

  5. Click Housekeeper to display the process page.

  6. Click the default Housekeeper server instance configured for garbage collection to display the parameters for that particular instance.

  7. Select Process Control Message Cleanup from the Operation Mode drop-down list.

  8. Select Enabled from the Pruning and Collection drop-down lists in the Housekeeping Operations section.

  9. Ensure all other Housekeeping Operations are disabled.

  10. Enter 60 in the Frequency of Execution of Housekeeper Process field.

  11. The Age Threshold parameter units are measured in minutes when process control message cleanup is configured. Because few of these messages are generated on a daily basis, 30 is an acceptable value for this parameter.

  12. Select On Startup from the Run Task drop-down list.

  13. Optionally, enable the Support Log Miner Recovery parameter to recover messages with LogMiner.

    See Also:

    "Setting Up LogMiner to Recover Mail"for information about setting up LogMiner for mail recovery
  14. Click Apply.

  15. Return to the Mail Application page.

  16. Select the Housekeeper server and click Start to bring up the server.

Setting Up LogMiner to Recover Mail

In order to set up mail recovery, you must enable supplemental logging for the Oracle Collaboration Suite Database and configure the Housekeeper server to record the messages being deleted into the redo logs.

Setting up LogMiner involves the following tasks:

Oracle Collaboration Suite Database Tasks

Perform the following tasks on the Oracle Collaboration Suite Database to set up LogMiner:

  1. Ensure that the database is in archivelog mode.

  2. Specify the archive log destination in the init.ora file, as follows:

    log_archive_dest_1='location=full_path'
    
    
  3. Specify the archive log format in the init.ora file, as follows:

    log_archive_format=arch_%t_%s_%r.arc
    

Enabling Supplemental Logging

To enable supplemental logging for the Oracle Collaboration Suite Database:

  1. Start SQL*Plus and log in as sys, as follows:

    $ sqlplus sys/sys_password
    
    
  2. Enter the following SQL command:

    SQL > alter database add supplemental log data (primary key,unique index) 
    columns;
    

Configuring the Housekeeper Server to Record Deleted Messages

The following procedure is essentially the same as that described in "Process Control Message Cleanup" except the following procedure describes just configuring the Housekeeper to record deleted messages.

To configure the Housekeeper process to record the messages being deleted into the redo logs:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click Mail Application in the System Components section to display the Mail Application page.

  3. Click Housekeeper.

  4. Click the Housekeeper instance where the collection parameter is configured.

  5. Enable the Support Log Miner Recover parameter in the General Parameters section.

  6. Click Apply.

  7. Return to the Mail Application page.

  8. Click Start.

Oracle Text

Integrating Oracle Text and Oracle Mail extends the e-mail server functionality, enabling text search in e-mails, e-mail theme generation, and e-mail formatting functions such as highlight and markup.

Oracle Text integration support is installed by default when Oracle Mail is installed. However, if the database user ctxsys is not present at the time of installation, the Oracle Text installation will fail.

Note:

This feature is only available when the Oracle Collaboration Suite Database is Oracle Database 10g Enterprise Edition.

The user attribute Text Indexing enables users to perform server-side search on mail message bodies.

See Also:

"Managing Oracle Mail Users" to enable a user for message body search or change this attribute value for all new users created by default

Oracle Mail support for Oracle Text provides both a Java Software Developer's Kit (SDK) and a PL/SQL SDK for application integration. Applications can interface with the SDKs to use or extend Oracle Text functionalities.

Except for zipped attachments, Oracle Mail message bodies and attachments can be indexed and later searched for text strings, themes, gists, or formatting, such as highlight and markup. To be searchable, the contents of a mail message body must be indexed by the Oracle Text server. If indexing is enabled, Oracle Mail puts candidate messages into a queue for Oracle Text to index. The created index is later usable for performing a message body search.

Text indexing enables searching message bodies for content, using IMAP clients that support message body searching or using the Oracle Ultra Search component of Oracle Collaboration Suite. This feature is available only to users whose accounts are text-enabled.

Applications that integrate with Oracle Mail can use Oracle Text indexing through the PL/SQL and Java APIs.

See Also:

Chapter 1 "PL/SQL API" Reference in Oracle Mail Application Developer's Guide for more information on using Oracle Mail APIs to find themes and gists in e-mail messages

This section includes the following topics:

Enabling E-mail Body Searching for Various Languages

The text index for e-mail body searching is created with the Oracle Text BASIC_LEXER, which supports English and most western European languages that use white space delimited words. For other languages that are not supported by Oracle Text BASIC_LEXER, such as Chinese, Japanese, and Korean, e-mail body search does not function.

To enable message search for Chinese, Japanese, or Korean:

  1. Stop the Housekeeper process using the Application Server Control Console for Collaboration Suite.

    See Also:

    "Starting, Stopping, Restarting, or Refreshing All Server Instances" for information about stopping a process
  2. Run the following SQL commands as database user es_mail:

    SQL> @recreate_text_index.sql
    
    
  3. Select and enter the text lexer for indexing messages from the list, as shown in the following example. The script will rebuild the text index using the selected lexer.

    SQL> @recreate_text_index
    Use this script to customize or update the index used for text
    searching.  Choose a lexer and a default character set for mail
    messages.
    
    LEXER: a lexer is a program component responsible for recognizing
    words in a document for a specific language.  Choose one of the 
    following representing the primary language used in the system.
    
    1 - chinese_lexer   for Chinese
    2 - japanese_lexer  for Japanese
    3 - korean_lexer    for Korean
    4 - default_lexer   for other languages
    (this is the default if no input is received)
    
    Enter the desired lexer number[4]: 4
    
    DEFAULT CHARACTER SET: when a mail message body or a text attachment
    of a mail message does not contain a character set tag in the
    header, the system uses this default character set to recognize the
    mail message for indexing.  Choose one of the following
    representing the primary character set that client mail programs
    use in this environment.  Note that this is NOT necessarily
    the character set used in the mail database.  For a list of
    recommended default character sets for popular languages, 
    refer to the text file default_charset.txt present in the 
    same diretory.
    
    1 - US-ASCII (US7ASCII)          2 - UTF-8 (AL32UTF8, default)
    3 - SHIFT_JIS (JA16SJIS)         4 - EUC-JP (JA16EUC)
    5 - ISO-2022-JP (ISO2022-JP)
    6 - EUC-KR (KO16MSWIN949)        7 - ISO-2022-KR (ISO2022-KR)
    8 - GBK (ZHS16GBK)               9 - GB18030 (ZHS32GB18030)
    10 - BIG5 (ZHT16MSWIN950)        11 - BIG5-HKSCS (ZHT16HKSCS)
    12 - WINDOWS-1250 (EE8MSWIN1250) 13 - WINDOWS-1251 (CL8MSWIN12510)
    14 - WINDOWS-1252 (WE8MSWIN1252) 15 - WINDOWS-1253 (EL8MSWIN1253)
    16 - WINDOWS-1254 (TR8MSWIN1254) 17 - WINDOWS-1255 (IW8MSWIN1255)
    18 - WINDOWS-1256 (AR8MSWIN1256) 19 - WINDOWS-1257 (BLT8MSWIN1257)
    20 - WINDOWS-1258 (VN8MSWIN1258) 21 - TIS-620 (TH8TISASCII)
    
    Enter the default character set number[2]: 2
    Setting default character set and recreating the text index...
    (this may take a while, please wait...)
    Setting default character set...
    Creating text index...
    
    PL/SQL procedure successfully completed.
    
    Done.
    SQL> exit
    
    
  4. Ensure that a Housekeeper server instance is configured for Oracle Text indexing using the Application Server Control Console for Collaboration Suite.

  5. Start the Housekeeper process using the Application Server Control Console for Collaboration Suite.

    See Also:

    "Starting, Stopping, Restarting, or Refreshing All Server Instances" for information about starting a process

    Note:

    Indexing is limited to only one lexer.
Verifying Oracle Text Installation

Before text indexing can be used, Oracle Text must be installed and configured. Oracle Text is installed by default when Oracle Database 10g Enterprise Edition is installed. The Oracle Mail support for Oracle Text installation fails if the database user ctxsys is not present at the time of installation.

To verify that the Oracle Text option was installed and configured on the Oracle Collaboration Suite Database, run the following SQL query as sysdba:

SQL> select comp_id, version, status from dba_registry;

If Oracle Text was installed correctly, an output similar to following displays:

COMP_ID                        VERSION                        STATUS 
------------------------------ ------------------------------ ----------- 
… 
CONTEXT                        10.1.0.4.0                      VALID 

If Oracle Text was not installed and configured on the Oracle Collaboration Suite Database, it must be configured manually.

See Also:

Oracle Collaboration Suite Installation Guide for Solaris Operating System for further instructions on installing and configuring Oracle Text
Creating a Housekeeper Server Instance to Index Text

Oracle Text periodically processes a message queue filled by a Housekeeper server instance.

Text search performance can be improved by periodically optimizing the existing Oracle Text index. Since many indexed messages are deleted or moved, the Oracle Text index bits are no longer consecutive, slowing down searching. Search time can be reduced by periodic clean-up of the Oracle Text index, removing entries that refer to deleted or moved messages.

Optimization can be done by the Housekeeper server. Assign a new Housekeeper instance to do this unless performance requires optimization to be done at the same frequency as indexing.

To create a Housekeeper server instance to queue messages for text indexing:

Note:

This procedure combines the Statistics Cleanup operation mode with the Text Synchronization and Text Optimization tasks.
  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select the Housekeeper server and click Stop to bring down the server.

  5. Click Housekeeper to display the Housekeeper page.

  6. Click Create to create a new Housekeeper server instance.

  7. Click the new Housekeeper server instance to display its parameter page.

  8. Select Enabled from the Text Synchronization and Text Optimization drop-down lists in the Housekeeping Operations section.

  9. Ensure all other Housekeeping Operations are disabled.

  10. In the Frequency of Execution of Housekeeper Process field in the General Parameters section, enter how often the Housekeeper should queue messages for indexing, in minutes.

    For example, if the Housekeeper should queue messages for indexing every two hours, enter 120 in the field.

    Note:

    Indexing too frequently will result in increased database server load and degraded search performance, but indexing too infrequently will cause more new messages to be unavailable for search. The recommended frequency is 1 to 2 hours.
  11. Click Apply.

  12. Return to the Mail Application Service Targets page.

  13. Select the Housekeeper server and click Start to bring up the server.

Enabling Text Indexing for a User

See Also:

"Modifying E-mail User Attributes" to enable text indexing for users

Tertiary Storage

Administrators can configure Oracle Mail to move messages to tertiary storage based on the age of the message. This process frees up valuable space on the primary disk for newer, more frequently accessed messages, and enables users to still access messages in tertiary storage, as before.

Message stores tend to grow constantly. Mail continually enters the store, and while many messages are deleted, more are saved. Generally, older messages are accessed less, so storing them on less expensive, slower disks while keeping them accessible to users may be an acceptable way to reduce costs. Depending on the storage mechanisms used for tertiary storage, users should not be aware that their older messages have been moved to a different physical disk.

Tertiary storage in Oracle Mail is enabled through the Housekeeper. The Housekeeper can be set to move older messages to a tablespace named ESTERSTORE, which is reserved for tertiary storage of old messages. The age of messages to be moved to tertiary storage is set through the Age Threshold Housekeeper general parameter.

Note::

For the name of mail store tablespaces and their default storage parameters refer to the $ORACLE_HOME/oes/install/sql/tblspc.sql script.

Tertiary storage can be initially planned as part of an Oracle Mail system or it can be implemented later. By default, the ESTERSTORE tablespace is created on the same disk as all other tablespaces when initially installing Oracle Mail.

Table 3-4 gives the four considerations in determining how tertiary storage tablespace is handled.

Table 3-4 Tertiary Storage Usage and The ESTERSTORE Tablespace

If Tertiary Storage is: The ESTERSTORE Tablespace:

Never enabled for the system

Remains empty.

Enabled for Oracle Mail

Is set up on a disk different from the primary mail store, either before or after installing Oracle Mail.

To be implemented for a new Oracle Mail system

Is created on a disk different from the primary mail store, before installation of Oracle Mail.

To be implemented for an existing Oracle Mail system

Is moved, with the es_tbody table, from its default location on the same disk as the primary mail store onto a separate disk.


See Also:

Oracle Database Administrator's Guide for more information on creating and moving tablespaces

This section includes the following topics:

Moving the ESTERSTORE Tablespace

To move the ESTERSTORE tablespace after Oracle Mail has already been installed:

  1. Back up the database.

  2. Identify the datafiles for ESTERSTORE tablespace.

    For example: The following query of the data dictionary view DBA_DATA_FILES lists the datafile names of the ESTERSTORE tablespace:

    select file_name from dba_data_files
    where tablespace_name='ESTERSTORE';
    FILE_NAME
    ------------------------------------------
    /usr/app/oracle/product/mailstore/dbf/erstore.dbf
    
    
  3. Take the ESTERSTORE tablespace offline.

    alter tablespace esterstore offline normal;
    
    
  4. Copy the datafiles for the ESTERSTORE tablespace using the operating system, to a different disk.

  5. Use the ALTER TABLESPACE statement with the RENAME DATAFILE clause to change the file names for the ESTERSTORE tablespace to a new location.

    alter database esterstore rename datafile '/usr/app/oracle/product/mailstore/dbf/erstore.dbf' to
    'file_name_in_new_location';
    
    
  6. Bring the ESTERSTORE tablespace online.

    alter tablespace esterstore online;
    

    See Also:

    Oracle Database Administrator's Guide
Enabling Tertiary Storage

After the ESTERSTORE tablespace has been created, create and configure an instance of the Housekeeper server to enable tertiary storage:

Note:

This procedure combines the Tertiary Storage operation mode with the Expiration task.
  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Select the Housekeeper server and click Stop to bring down the server.

  5. Click Housekeeper to display the Housekeeper page.

  6. Click Create to create a new Oracle Mail Housekeeper instance.

  7. Click the new Housekeeper instance to display its parameter page.

  8. Select Tertiary Storage from the Operation Mode drop-down list in the Housekeeping Operations section.

  9. Select Enabled from the Expiration drop-down list in the Housekeeping Operations section.

    When Expiration is enabled, each folder deletes messages older than the number of days specified in the Age Threshold parameter.

  10. Ensure all other Housekeeping Operations are disabled.

  11. In the Frequency of Execution of Housekeeper Process field, enter how often the Housekeeper should perform tertiary storage, in minutes.

    For example, if the Housekeeper process performs tertiary storage once a day, enter 1440 (24*60).

  12. In the Age Threshold field, enter the age, in days, of messages you want to move to tertiary storage. The default is 30 days.

    For example, if you enter 60 in this field, messages that are 60 days old are moved to tertiary storage.

  13. Select On Startup from the Run Task drop-down list.

  14. Click Apply.

  15. Return to the Mail Application Service Targets page.

  16. Select the Housekeeper server and click Start to bring up the server.

    The Housekeeper process periodically moves messages of the appropriate age into tertiary storage.

Housekeeper Server Parameters

See Also:

"Oracle Mail Housekeeper" for detailed information on Housekeeper parameters

Managing Housekeeper

See Also:

"Managing Oracle Mail Servers and Instances" for instructions on creating, deleting, and modifying Housekeeper instances

List Server

List servers enable public distribution list management as well as integration with other messaging services or applications.

Users can own and administer public distribution lists as a way to distribute information to groups of people or as a discussion forum. If desired, restrictions can be placed on membership, requiring prior approval, and on outgoing messages, requiring screening by one or more moderators who control what messages are sent out. For example, a distribution list administrator may screen out advertisements.

The List Server is installed with Oracle Mail, with default values set for all List Server parameters. Administrators can modify these values to meet performance or feature requirements. For example, a distribution list with a large number of members requires changing the Oracle Internet Directory Query Entry Return Limit parameter. It must be configured to return a large number of entries to enable the list resolution API to return all the members. This parameter can be configured through oidadmin.

APIs provided with the List Server enable users to customize distribution lists and messages sent out to a distribution list. For example, marketing campaigns can send special non-transferable offers readable only by the intended recipients. As another example, a user can query a sales information database to create a distribution list of all customers who have made purchases in the past three months. Customers on that distribution list can then receive e-mail coupons with discounts based on the amount of their purchases.

This section includes the following topics:

List Server Mail Interface

The List Server features a mail interface that enables distribution list members and owners to perform certain tasks. Depending on the distribution list type and parameters, members and owners can subscribe, unsubscribe, suspend, resume, or invite members to a distribution list. The command messages are sent to a particular e-mail address of the form list_name-admin@domain. For example, if a distribution list name is list@foo.com, commands are sent to list-admin@foo.com.

See Also:

Oracle WebMail online help for a complete list of commands with syntax, description, and examples

Archiving Distribution List Posts

A distribution list owner can have all posts sent to a distribution list stored as messages in an archive in the NNTP server archives. Such an archive operates as a newsgroup and can be browsed using a standard news client.

An administrator must specify archiving as a property of the distribution list in order to archive messages, as described in Table 2-4, "Distribution List Parameters".

When a distribution list is archived, a newsgroup is created with a name reflecting the original distribution list. For example, the name of the NNTP archive newsgroup for the distribution list abc@foo.com becomes the following:

ListArchive.abc

Once a distribution list is created, the domain administrator can begin archiving, which affects only e-mails sent after a distribution list's archive property is set. No messages prior to that time are archived.

Distribution list archives must have the post parameter disabled. A mail is added to the archive only when a mail is delivered to the distribution list. E-mails cannot be added to an archive by any other mechanism.

Distribution list archives must be local to the domain of the distribution list. Global newsgroups cannot be associated with a distribution list as an archive.

Administrators can set expiration periods for distribution list archives, such as one month, meaning that messages are only stored in the archive for one month before being deleted. The expiration policy for a distribution list's archive is the corresponding newsgroup's expiry attributes.

External Distribution Lists

External distribution lists provide a way for the membership of a distribution list to be stored outside of Oracle Collaboration Suite, while using the List Server to deliver e-mails to such a distribution list. A distribution list owner or domain administrator can configure a distribution list to be external by enabling the external list option in the distribution list properties page, as described in Table 2-4, "Distribution List Parameters". A PL/SQL procedure for resolving the addresses of the distribution list members must be created on the Oracle Collaboration Suite Database to which the List Server is connected.

The PL/SQL procedure must have the following syntax:

Note:

Database links are not supported for any of the List Server PL/SQL callouts (either for PL/SQL mail-merge or for external distribution lists). The procedures for both of these features must reside on the queue database (the database to which the list server is connected). These procedures can then, in turn, refer to procedures on other databases using database links. But the server itself does not support database links.
procname(session_ID IN NUMBER,
   msg_obj IN MAIL_MESSAGE_OBJ,
   list_ID IN VARCHAR2,
   return_count IN NUMBER,
   count OUT NUMBER,
   recipients OUT RECIPIENTS_TABLE)

  • The session_id and msg_obj parameters can be used by the PL/SQL procedure developer to call the MAIL_MESSAGE PL/SQL API and fetch any relevant information about the message being processed

    See Also:

    "MAIL_MESSAGE Package" in Chapter 1 of Oracle Mail Application Developer's Guide for more information about the MAIL_MESSAGE package
  • list_ID is the e-mail address of the list being resolved

  • return_count indicates whether the procedure should return the number of recipients in the list or the recipients itself. A value of 1 indicates the count is to be returned and 0 indicates that the recipients are to be returned.

  • The count of the recipients are returned in the count variable if the value of return_count is 1

  • The recipients are returned in the recipients table with one row for each recipient if the value of return_count is 0

The List Server calls the procedure twice while resolving an external distribution list. Initially, the value passed for the return_count parameter is 1. It receives, in return, the count OUT NUMBER parameter, containing just the number of recipients in the list, and not the list of recipient addresses.

Subsequently, the value passed for the return_count parameter is 0, which causes the procedure to return a table of recipients in the recipients OUT parameter. Each row of that table contains a recipient's full e-mail address.

Example

The following is an example of how to create the get_cust_list PL/SQL procedure.

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Click List Server to display the List Server page.

  5. Navigate to the list cust_list@acme.com.

  6. Edit the properties of the list.

  7. Select True in the list box for the Group Is External field.

  8. Set the External Procedure parameter to get_cust_list.

  9. Connect as es_mail to the Oracle Collaboration Suite Database to which the List Server is connected and create the following PL/SQL procedure:

    procedure get_cust_list(session_id IN NUMBER,
       msg_obj IN MAIL_MESSAGE_OBJ,
       listid IN VARCHAR2,
       return_count IN NUMBER,
       count OUT NUMBER,
       recipients OUT RECIPIENTS_TABLE)
    l_hdr varchar2(2000);
    l_cnt number;
    begin
    -- First get the sender of the message being processed
    
       mail_message.get_header(session_id, msg_obj, 'From', l_hdr);
    
    -- Query the table to get the customer count based on the sender's region
    
       if (instr(lower(l_hdr), 'sales_us@foo.com', 1, 1) > 0)
          then select count(*) into l_cnt from customer_list where region='US';
    
          else
             select count(*) into l_cnt from customer_list where region!='US';
       end if;
    
    -- If the count is requested, then return the count
    
       if (return_count = 1)
          then count := l_cnt;
    
          else
    
    -- Create a recipients_table object
    
             recipients := recipients_table();
             recipients.extend(l_cnt);
    
    -- Query the table to get the customer list based on the sender's region
    
          if (instr(lower(l_hdr), 'sales_us@foo.com', 1, 1) > 0)
             then select mailid from customer_list where region='US'
             bulk collect into recipients;
    
             else
                select mailid from customer_list where region!='US'
                bulk collect into recipients;
    
          end if;
       end if;
    end;
    
    

The previous example assumes that cust_list@acme.com is a list of customers maintained in a database table by a different application. This procedure uses a table called customer_list, described in Table 3-5.

Assuming that the customer_table is populated with the customer e-mail IDs and their regions, if the user sales_us@foo.com sends a message to the list, the message is delivered to all the customers in the US region. Mail from any other e-mail address to this list is delivered to all customers on the list, regardless of region.

Table 3-5 customer_list Table

Column Name Data Type Explanation

mailid

varchar2 (256)

E-mail ID of a customer

region

varchar2 (256)

Geographical region of the customer


Note:

The signature of the external lists procedure has changed in this release. To continue to use the Oracle Collaboration Suite Release 2 (9.0.4) signature for external lists, add a flag -external_list_904 in the Process Flags parameter of the List Server and restart the List Server.

Distribution List Digests

The List Server includes a mail digest feature for distribution lists. This feature enables a member of a distribution list to receive a single message containing all posts in a day or a week to a specific distribution list, rather than receive the individual messages, as they are sent.

Distribution list owners control whether digests are enabled on the lists they own or not. If digests are enabled for a distribution list, a member can choose to receive a daily or a weekly digest, by changing the setting through the Oracle WebMail client or by setting the frequency option in subscribe command (described in the List server mail interface section).

If the distribution list is also configured for archiving, a member can choose not to receive any messages. The user will still be able to browse through the archives of the distribution list and not receive any of the messages sent to the list. By default, a user will receive all messages sent to the distribution list as they are delivered.

All the mail digests are sent in HTML format with a table of contents listing all the postings in that digest. Users can navigate to the specific post by clicking the subject of the post in the table of contents.

Distribution List Bounce Processing

It is possible that certain members of a distribution list (especially those in different domains) are invalid or do not exist. In such cases a DSN is generated when a message is sent to one of these users and sent to the sender of the message.

The List Server can be configured to automatically handle these DSNs. If the distribution list owner enables bounce processing for a list (using the Oracle WebMail client), the List Server receives all DSNs and a record is maintained.

Once the number of bounces for a particular e-mail address reaches a preconfigured threshold, the owner of the distribution list is notified of this, along with the action the owner can take to remove the invalid recipient mail ID from the list. The distribution list owner can then unsubscribe the user from the list.

Multiple Language Responses

With Oracle Collaboration Suite 10g, all responses sent out by the List Server to users (in response to commands or requests for message moderation, for example), are delivered in the preferred language of the recipient. Users can change their preferred language using the Directory Administration Services application. For more details refer to

Mail Merge

Mail merge enables customized mail to be delivered to every member of a distribution list. Distribution list owners or domain administrators must decide on a mail merge tag for a list and set it in the distribution list properties page. The mail merge tag can be a single word or a group of words. This feature can be enabled for a distribution list by providing a value for the merge tag property of the list, as described in Table 2-4, "Distribution List Parameters". Table 3-6 lists the two types of mail merge that the List Server supports.

Table 3-6 Types of Mail Merge and Customizable Features

Type of Mail Merge Description Customizable Features

Standard mail merge

Message contents can be customized for each recipient with the values in the Customizable Features column.

Recipient's mail address (recipient_mail_address)

Recipient's first name (recipient_first_name)

Recipient's last name (recipient_last_name)

Recipient's full name (recipient_full_name)

Current date (current_date)

Current time (current_time)

PL/SQL mail merge

Similarly customizable, but also enables embedding of PL/SQL in messages. (The PL/SQL function must return a varchar2 string.)

For each recipient, the PL/SQL function is executed and the output is embedded in the mail before delivery. Any parameter defined for standard mail merge can be included as a parameter to the PL/SQL function.


For standard mail merge, use the mail merge tag appropriate to a corresponding section of the mail. For example, if the distribution list's mail merge property is orcl, and the mail is addressed with the recipient's full name, the mail looks like the following:

Dear <orcl>recipient_full_name</orcl>,
... 
... 

For PL/SQL mail merge, if you have a PL/SQL getSalary function that returns an individual's salary, given his mail address, you can use it in the mail. For example, you can embed the function call in the mail you send to a list of employees, letting them know their salaries, as follows:

Dear <orcl>recipient_full_name</orcl>,
    Your salary is <orcl>getSalary(recipient_mail_address)</orcl>. 
    ... 

Note:

Database links are not supported for any of the List Server PL/SQL callouts (either for PL/SQL mail-merge or for external distribution lists). The procedures for both of these features must reside on the queue database (the database to which the list server is connected). These procedures can then, in turn, refer to procedures on other databases using database links. But the server itself does not support database links.
Dear <orcl>recipient_full_name</orcl>, 
    Your salary is <orcl>getSalary(recipient_mail_address)@dblink</orcl>. 
    ... 

Example

Note:

The following example assumes that distribution lists and users have been set up correctly with the List Server process configured and running.

The following example shows how to create the get_sal PL/SQL procedure:

  1. Open the Application Server Control Console for Collaboration Suite.

    See Also:

    "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite
  2. Click the application server instance where Oracle Mail is installed.

  3. Click Mail Application in the System Components section to display the Mail Application page.

  4. Navigate to the list all_emp@acme.com.

  5. Edit the properties of the list and set the Group merge tag parameter to mail merge.

  6. Connect as es_mail to the mail store supported by the List Server and create the following PL/SQL procedure:

    CREATE OR REPLACE FUNCTION get_sal(email IN VARCHAR2) RETURN VARCHAR2
    mon varchar2(10);
    tmp number;
    ret varchar2(4000);
    begin
    -- get the month and salary value for the user
    select month, salary into mon, tmp from emp_payroll where employee=email;
    
    -- concatenate to form a string
    ret := mon || ' is $' || tmp;
    
    return ret;
    end;
    
    

The procedure assumes that some application puts employee payroll information into a database table. Table 3-7 lists the columns contained in the emp_payroll table in the previous example.

Table 3-7 Example emp_payroll Table

Column Name Data Type Explanation

employee

varchar2 (1000)

Mail ID of an employee

month

varchar2 (10)

Month for which the salary is stored

salary

number

Salary of the employee


Following is an example of a message with mail merge tags embedded in it. This sends a mail to each recipient in the distribution list all_emp@acme.com with each person's salary details.

Dear <mailmerge>recipient_full_name</mailmerge>, your salary for the month of <mailmerge>get_sal(recipient_mail_address)</mailmerge>. The salary has been credited into your account.

Thanks

Payroll

Scheduled Mail Delivery

Scheduled mail delivery enables administrators to schedule mail delivery to occur at a particular time, such as during low traffic hours, possibly minimizing server loads during peak usage hours. Otherwise, delivery of very large messages or of mailings to distribution lists with large numbers of subscribers can degrade performance.

This feature can be enabled by providing a value for the mail merge property of the distribution list. Specify the delivery time for a message by putting the schedule mail delivery tag anywhere in the mail. The following example illustrates this, using orcl as the tag for the mail merge property of the distribution list:

<orcl>send_schedule=DD-MON-YYYY hh24:mi [+/-TZH:TZM]</orcl> 

<orcl>send_schedule=23-JUN-2003 21:45 -08:00</orcl>

Note:

+/- before TZH:TZM is required.

Table 3-8 lists parameter descriptions for the send_schedule delivery tag.

Table 3-8 send_schedule Parameter Descriptions

Parameter Description

DD

The date

MON

The three letter abbreviation for the month

YYYY

The year

hh24

The time in a twenty-four hour period

mi

The time in minutes

TZH

The optional time zone hour offset

TZM

The optional time zone minute offset


If TZH and TZM are not specified, the List Server uses the sender's time zone to schedule delivery of the mail.

List Server Parameters

See Also:

"Oracle Mail List Server" for detailed information on List Server parameters

Managing List Servers

See Also:

"Managing Oracle Mail Servers and Instances" for instructions on creating, deleting, and modifying List Server instances

NNTP Server

Network News Transport Protocol (NNTP) is used to distribute, query, post, and retrieve news articles from the Internet using a reliable stream-based mechanism. NNTP enables news-reading clients to select news articles from a central database, enabling subscribers to retrieve only the articles they want to read. The net news model provides indexing, cross-referencing, and message expiration. For server-to-server interaction, NNTP is designed to efficiently transmit net news articles over a reliable communication channel. Receiving and sending news articles is an interactive mechanism so that articles already present are not re-transmitted.

The Oracle Mail NNTP server can be used immediately upon installation and configuration of Oracle Collaboration Suite. In addition, the NNTP server uses the Oracle Collaboration Suite Database for article repository and the Oracle Collaboration Suite infrastructure directory service to store operational parameters. All protocol exchanges are performed over a stream-based connection.

During installation, default values are set for all Oracle Mail NNTP server parameters, that administrators can modify to meet performance or feature requirements of their site.

This section includes the following topics:

About News Servers

One or more news servers used by the same community of users is called a news site. Such sites can exchange news articles, transmitting locally posted articles to other sites to provide (and serve) a wider audience. News servers that exchange news articles are called peers.

News articles collected into similar-topic groupings are called newsgroups, such as articles about sailing or articles about the Oracle database. A peer can be configured to download articles only for particular newsgroups.

Users of news services exchange information by posting and reading news messages. Posting means a news user composes a message in a standard newsreader and sends it to the news server for storage, after which other users can read it.

The NNTP service maintains a list of peer servers, the newsgroups each peer server is configured to receive, and a list of newsgroups that the NNTP service delivers. The administrator for each newsgroup specifies the peers to be fed articles from that newsgroup. Once peers and newsgroups are configured and the feed rules are set, the service is ready for posting, reading, and feeding news.

The NNTP Inbound server receives news articles from clients and posts them to the Oracle Collaboration Suite Database.

The NNTP Outbound server takes articles from the Oracle Collaboration Suite Database and exchanges those articles with various peers.

Controlling News Storage

News articles are stored in the Oracle Collaboration Suite Database. Inbound and outbound servers connected to the Oracle Collaboration Suite Database only handle newsgroups created in that database. News articles are automatically expired strictly by the Housekeeper process.

The NNTP service also creates a history record to track articles already received, for which new entries are rejected by the server. Having a long history expiry avoids repeated entry of the same article into the mail store. History records are also subject to expiry and collection by the Housekeeper service.

The storage needed for NNTP service depends on the volume of incoming traffic and the expiry policy of the server instances, such as how long articles are retained. Each article's expiration date and history record are established when it is stored, and cannot later be changed.

Article Caching for Performance

You can configure the NNTP Inbound service to cache articles in memory, improving performance for articles that are requested repeatedly, since no new Oracle Collaboration Suite Database access is needed. Caching can only be done for articles less than 4 KB in size. You can adjust the total cache size to accommodate the number of articles you want to cache, to provide newsreaders with quicker response times for popular articles.

NNTP Processes

There are two types of newsgroup exchanges, which are known as feeds:

  • Inbound: The NNTP server receives the feed

  • Outbound: The NNTP server transmits the feed

The processes required for NNTP service are shared between the Inbound and Outbound servers.

This section includes the following topics:

NNTP Inbound

The NNTP inbound server has two functions:

  • Incoming feed: accepts news articles and waits for connections from remote hosts

  • Read or post: accepts and waits for connections from news-reading clients and enables them to post or read news articles

The NNTP inbound server identifies the connecting host for each connection it receives. For a peer, the server prepares to receive the news feed. If the connecting host is not a peer, it is a newsreader and only has permission to read and post articles.

When a newsgroup is configured, administrators can specify the number of peers that must be sent articles for that newsgroup. Based on the number of peers specified, the NNTP inbound server creates queues of incoming messages that must be passed on to other peers.

NNTP Outbound

The NNTP outbound server periodically connects to peer news servers configured to receive news feeds and offers a list of new articles queued for sending. Peer server parameters determine what is offered and what is acceptable or rejected by the peer.

See Also:

"Managing Peer Servers" for more information

The NNTP outbound server maintains a list specifying the newsgroups for each peer server. When the outbound server contacts a peer and provides a list of new articles, the remote host's response determines which articles are sent.

NNTP Server Parameters

See Also:

"Oracle Mail NNTP Inbound Server" and "Oracle Mail NNTP Outbound Server" for detailed information on NNTP server parameters

Managing NNTP Servers

See Also:

"Managing Oracle Mail Servers and Instances" for instructions on creating, deleting, and modifying NNTP server instances