3
Servers and Processes

This chapter discusses the different servers and processes of the Oracle Email system.

This chapter contains the following topics:

• Mail Store
• Managing Services and Processes
• IMAP4 and POP3 Processes
• SMTP Process
• Housekeeping Process
• List Server Process
• NNTP Server Process

  See Also: Chapter 5, "Security" for information on virus scrubber

Mail Store

The Oracle Email mail store is a database containing user folders and messages. The mail store 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 mail stores can store mail for one domain or several different domains, while a large domain can be supported by multiple mail stores.

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 Mail Store Connection Parameters

Using Oracle Enterprise Manager, perform the following steps to modify mail store default parameters:

1. Navigate to the Oracle Email Service Targets page.
2. Select a server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Click on Mail Store Connection Parameters.
4. Select the mail store for which you want to make changes.
5. Modify the parameters you want to change.
6. Click Apply.

Mail Store Parameters

Table 3-1 lists the mail store parameters.

Table 3-1 Mail Store Parameters

Parameter	Description
Timeout	Number of seconds a connection can remain idle before being terminated. Optimizes number of available connections for active users.
Maximum	Maximum number of connections that can be opened to the database. Once this value is reached, no more connections are allowed. Can be 1 or more.
Increment	Number of connections to the database that Oracle Email can add if the current number of connections is less than maximum. Can be 0 or more.
Minimum	Minimum number of connections to the database. Can be 0 or more.

Server Side Filters

Server side filters enable users to create mailbox filters on the server. Through the Oracle Webmail client, users can create rule-based actions, such as message foldering, vacation reply, spam filter, and wireless notification. Because filters are created on the server, actions carried out depend on if the user is online or using the client on which the rules were created on.

The SMTP inbound and outbound servers execute the rules as messages are received and sent.

Managing Services and Processes

This section discusses how to start, stop, reinitialize, and modify services and processes.

Starting an Oracle Email service starts all the processes constituting that service type, such as IMAP and POP.

Stopping an Oracle Email service sends a command to the service processes to shut down. System maintenance might be one reason an administrator might want to do this, such as upgrading the server hardware or software. The Oracle Email processes cannot be running while this kind of upgrade is being performed.

Whenever an Oracle Email process parameter is modified, the service must be reinitialized to make the changes take effect.

Reinitializing an Oracle Email service causes the processes to reload their operational settings from Oracle Internet Directory without stopping. Users continue to receive uninterrupted service.

Starting, Stopping, or Reinitializing All Server Processes

To start, stop, or reinitialize all server processes, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Click Start, Stop, or Reinitialize.

Creating a Server Instance

To create a server instance, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Click Create. This creates a new server instance with default parameters.

Creating a Server Instance with the Same Parameter Values as an Existing Server Instance

To create a new server instance with the same parameter values as an existing server instance:

1. Select the process with the parameters you want to replicate.
2. Click Create Like. This creates a new server instance with the same parameters as the selected server instance.

Deleting a Server Instance

Note: Deleting an Oracle Email process may disable some or all e-mail processes.

To delete a server instance, use Oracle Enterprise Manager as follows:

Note: A process must be shut down before it can be deleted.

1. Shut down the process you intend to delete.
2. Navigate to the Oracle Email Service Targets page.
3. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
4. Select the server process you want to delete.
5. Click Delete.

Starting a Server Instance

To start a server instance, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Select the server instance you want to start.
4. Click Start.

Stopping a Server Instance

To stop a server instance, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Select the server instance you want to stop.
4. Click Stop.

Reinitializing a Server Instance

Note: Servers must be reinitialized whenever parameters are modified. However, reinitializing does not interrupt user actions because the service is not brought down.

Use Oracle Enterprise Manager to reinitialize a server instance as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the service, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Select the server process you want to reinitialize.
4. Click Reinitialize.

Modifying Server Default Parameters

All new server instances are created with default parameters for that server type. The default parameters can later be modified for specific server instances.

Note: Servers must be reinitialized whenever parameters are modified.

To create a server instance with the same parameters as an existing server instance, use the Create Like option.

See Also: "Creating a Server Instance with the Same Parameter Values as an Existing Server Instance" for instructions on using the Create Like option.

To modify server default parameters, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Select Change Settings.
4. Modify the parameters you want to change.
5. Click Apply.
6. Reinitialize the server to make the changes take effect.

Modifying Parameters for a Specific Service Process

Note: Servers must be reinitialized whenever parameters are modified.

To modify parameters for a specific service process, use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Email Service Targets page.
2. Select the server type, such as IMAP, POP, SMTP, Housekeeping, or List server.
3. Select the server instance you want to modify.
4. Modify the parameters you want to change.
5. Click Apply.
6. Reinitialize the server instance to make the changes take effect.

IMAP4 and POP3 Processes

Table 3-2 describes the features of these two protocols for retrieving e-mail messages.

Table 3-2 Features of the POP3 and IMAP4 Protocols

Protocol	Description of Features
POP3, the Post Office Protocol	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.
IMAP4, the Internet Message Access Protocol	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. Also has primitives enabling optimization of online performance, especially for large MIME messages.

Process Architecture

The IMAP4 and POP3 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 IMAP4 and POP3 servers can be configured to create database connection pools to more than one mail store. Administrators use the IMAP4 and POP3 server parameters to control connection pool sizes.

Many operating systems limit the number of file descriptors and sockets that a single process can open. These limits can make it necessary to run more than one instance of an IMAP4 or POP3 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 processes.

IMAP and POP Server Parameters

See Also: Chapter 3, "Servers and Processes" for detailed information on IMAP and POP server parameters

Managing IMAP and Pop Servers

See Also: "Managing Services and Processes" for instructions on creating, deleting, or setting parameters for IMAP and POP servers

SMTP Process

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 DNS and the Oracle Internet Directory servers for information about hosts and users.

Various Configurations

The flexible architecture of Oracle Email enables users to set up a single or multi-tier configuration appropriate to a site's needs.

Single Node Setup

A single node setup has one mail store and SMTP server running on the same host, supporting a small numbers of users.

Single Mail Store Setup

A single mail store setup divides two processes into two tiers:

• The backend runs the database
• The middle tier runs SMTP and other protocol servers

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 mail exchanger (MX) records for the domain.

Multiple Mail Store Setup

A multiple mail store setup can have two configurations for multiple mail stores:

• Different hosts
• Same host

Each SMTP server serves only one mail store and each mail store must have an SMTP server. The mail stores on the SMTP hosts are used as SMTP queues and do not contain users.

Message Flow

The SMTP inbound service 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 accepts the message and inserts it into the corresponding queue based on the destination address.

If the recipient is an outside user, the message is stored in the relay queue awaiting further processing. If the recipient is local, the message is stored in the local delivery queue. The SMTPlocaldomains parameter, which contains the list of local domains is used to determine if 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 the rules against them, and sends them out using SMTP. For submitted messages, processing by the address rewriting and DNS resolution module happens first. After that, 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 can determine that the message is for 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 mail store are placed in the relay queue. The outbound server picks up and delivers the messages to the SMTP inbound service for the other mail store.

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 clients 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 thread pool, through which it performs user authentication and address resolution
• Database connection thread pool to the mail store, through which it delivers local messages.

  Note: The number of threads in each pool should depend on the number of users on the system and the e-mail load.

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.
• Anti-virus and anti-spam rules are applied
• Recipient rewriting rules are applied to the e-mail addresses to determine whether the message is to be delivered locally or sent to another mail store or out to the Internet
• SMTP message transfer agent accepts the message and inserts it into the corresponding queue based on the destination address.
• SMTP connection to the client is terminated, but if the message has local recipients, the worker thread continues to process the mail and perform local delivery

If administrators do not want the local messages to be processed immediately by the SMTP inbound server for performance reasons, messages can be stored in the submission queue and marked as submitted or unprocessed. The submission queue is handled by the SMTP outbound server. This is controlled by the server parameters. Messages created by the SDK applications are also marked as submitted in this situation.

During the address resolution phase, if the server determines that the message should be sent to a distribution list handled by the list server, it places the message in the list server queue. The list server then picks up this message, expands the distribution list and delivers the message.

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 SMTPlocaldomains parameter is used. This parameter contains the list of domains that are considered local.

If the recipient is an outside user, either on another mail store or on the Internet, the message is stored in the relay queue to await further processing by the SMTP outbound server.

See Also: "List Server Process" and "Rewriting Rules" for more information

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 thread 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 Enterprise Manager.

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.

Messages in the local delivery queue are destined for a local mailbox, so the queue processor 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 email 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 mail store 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.

Rewriting Rules

The SMTP address rewriting rules enables 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-3 Mailer, Host, User

Parameter	Description
Mailer	Specifies the Oracle Email SMTP process 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 inbound SMTP process parses each rule for every address in the message envelope during mail delivery.

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 machine puts MAIL FROM: [e-mail] in the message, the envelope From is [e-mail].

Similarly, the envelope To is derived from an incoming message line, such as RCPT TO: [e-mail]. 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-1.

Figure 3-1 shows e-mail addresses within a header, where an envelope is created by the From: and To: fields from the header.

Figure 3-1 Message Header

Text description of the illustration rewrite5.gif

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: [e-mail]
250 [e-mail]... Sender ok
RCPT TO: [e-mail]
250 [e-mail]... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: [e-mail]
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: [e-mail]
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 renaming 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 Email 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-4, used in this format:

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

where:

Table 3-4 Rewriting Rule Format

Format	Description
Pattern (LHS)	Specifies the pattern to be changed
Result (RHS)	Specifies that whenever the pattern 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's 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: it 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-2 Changing First.Last

Text description of the illustration example1.gif

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-3 Changing Uppercase to Lowercase

Text description of the illustration example2.gif

For example:

[e-mail] resolved by the Pattern (LHS)rule,

Result (RHS)= [e-mail]
$* (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.

rhs $*.$* where lhs $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.

Designing an Oracle Email Address Rewriting Rule

Oracle Email uses two types of address rewriting rules:

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

Figure 3-4 Recipient and Sender Rewriting Rules

Text description of the illustration rewrite.gif

Rules can be written through Oracle Enterprise manager. Rules 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,$[e-mail], "This changes [e-mail] to [e-mail]"
  
  

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 1st 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 [e-mail] 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.$[e-mail], "This changes fred.jones@uuhost to 
  [e-mail]"
  
  

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 [e-mail].

Figure 3-5 Message Flow through Rewriting Rules

Text description of the illustration example3.gif

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: Chapter 3, "Servers and Processes" for detailed information on SMTP parameters

Managing SMTP Servers

See Also: "Managing Services and Processes" for instructions on creating, deleting, or setting parameters for SMTP servers

Housekeeping Process

Housekeeping is a standalone component, operating in the background, that directly interacts with the mail store database to do cleanup tasks. During Oracle Email installation, a housekeeping job is created by default with a default configuration, but administrators can manually alter its schedule or add more instances of the job.

Job scheduling and management are handled by Oracle Enterprise Manager. While a housekeeping process is running, it responds to administrative requests to report job progress, reinitialize job parameters, or shut down.

See Also: Oracle Enterprise Manager Administrator's Guide for more information on job scheduling.

Other servers mark messages for deletion by the housekeeper after their intermediate output is no longer needed, and housekeeping removes it, which is called garbage collection. Three types of agents produce such intermediate output that is later destroyed by housekeeping:

• SMTP
• IMAP and POP3
• Housekeeping itself

Housekeeping performs tasks in multiple stages, some of which produce messages for another stage. For example, during message expiration processing, the housekeeping process produces messages later consumed by the pruning stage.

The SMTP server creates and processes messages that are mostly in transit, which stay in queues until the SMTP server finishes processing them and marks them as processed. Messages so marked are sent to the housekeeping process, which removes them from the system. Messages that users delete through clients are marked for deletion and picked up by housekeeping for deletion from the mail store.

The housekeeping log files, located in the mail store and the middle tier, respectively contain information on the progress of housekeeping tasks and the status of the process.

See Also: "SMTP Process" for more information

Oracle Text

Integrating Oracle Text and Oracle Email 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 is installed by default when Oracle Email is installed. However, if database user ctxsys is not present at the time of installation, the Oracle Text installation will fail.

Two user-level Oracle Internet Directory parameters are associated with the configuration of Oracle Text:

• User Index Type: Enables text search capability for users. Set to 1 or 2 for a user enables that user to do server side search on message bodies, using any supported client.
• Doc Binary: Controls what is used for e-mail theme generation and e-mail formatting functions: only the text, or the complete contents of e-mail messages.

The following table describes the parameter values for User Index Type and Doc Binary.

Table 3-5 Oracle Internet Directory Parameter Name & Associations

Oracle Internet Directory Parameter Name & Associations	Type	Possible Values
User Index Type/ text search	number	0: do not index incoming e-mail (default) 1: for incoming e-mails, index text contents only 2: for incoming e-mails, index both text and binary contents
Doc Binary/ document service	Boolean	false: when requesting document service, process only text contents (default) true: when requesting document service, index both text and binary contents

These user-level configuration parameters are independent of each other and are viewable as domain level preferences. They are inherited by all new users created in the domain. To view or modify parameter values, use Oracle Enterprise Manager.

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 Email 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 Email puts candidate messages into a queue for Oracle Text to index. The created index is later usable for performing a message body search.

Oracle Email user accounts can be enabled for text searching only, or for binary search as well. Text indexing enables searching message bodies for content, using IMAP clients that support message body searching or using Oracle Collaboration Suite's Ultra Search component. This feature is available only to users whose accounts are text-enabled.

A user enabled for text searching can search for strings in text and HTML files only.

A user enabled for text and binary searching can also search for strings in binary files, such as PDF files.

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

See Also: Oracle Email Application Developer's Guide for more information on using Oracle Email APIs to find themes and gists in e-mail messages

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 Email is installed. The Oracle Text installation fails if the database user ctxsys is not present at the time of installation.

To verify that the Java and Oracle Text Options were installed and configured on the mail store 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                        9.2.0.2.0                      VALID 

If Oracle Text was not installed and configured on the mail store database, it must be configured manually.

See Also: Oracle Collaboration Suite Installation Guide for further instructions on installing and configuring Oracle Text.

Creating a Housekeeper Process to Index Text

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

To create a housekeeping instance to queue messages for text indexing, perform the following steps:

1. Using Oracle Enterprise Manager, navigate to the housekeeping page.
2. Create a new Oracle Email housekeeping instance by clicking Create or Create Like.
3. Click on that housekeeping instance to go to its parameter page.
4. Enable Text Synchronization.
5. Disable Pruning and Collection options.
6. In the Process Sleep Duration field, enter how often the housekeeper should queue messages for indexing, in minutes.

   For example, if the housekeeper should queue messages for indexing every three minutes, enter 3 in the field.

   Note: Set the housekeeper to index messages as frequently as clients check for new mail. For example, five minutes is a good starting point.

7. Set Execution Mode to Daemon.
8. Click Apply.
9. Return to the housekeeping page.
10. Click Start.

    As an ongoing process, housekeeping periodically collects newly arrived messages to Oracle Text for indexing.

Enabling Text Indexing for a User

To enable content indexing for a user, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select User.
3. Select Modify User.
4. Enter the user ID.
5. Select domain from pulldown list, if necessary.
6. Click Find.
7. Click on the user's name to bring up the policy page for that user.
8. Select the Document Binary Search parameter.
9. Set the Text Synchronization parameter of the user by selecting Text Only.
10. Click OK.

System administrators can enable text indexing for all users on the system; domain administrators can do so only for users within the domain they manage. Once text indexing is enabled for a user, message body searching becomes available as soon as the housekeeper has indexed that user's messages.

Improving Performance through Optimized Text Index

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 a housekeeper process. A new housekeeper instance should be assigned to do this unless performance requires optimization to be done at the same frequency as indexing.

To create a housekeeper process to optimize the text index, perform the following steps:

1. Using Oracle Enterprise Manager, navigate to the housekeeping page.

Create a new Oracle Email housekeeping instance by clicking Create or Create Like.

1. Click on that housekeeping instance to go to its parameter page.
2. Enable Index Optimization.
3. Ensure all other GC Operations are disabled.
4. In the Process Sleep Duration field, enter the frequency the housekeeper should index messages in minutes.

   For example, if the housekeeper should queue messages for indexing every three minutes, enter 3 in the field.

   Note: Set the housekeeper to index messages about as frequently as clients check for new mail. For example, five minutes is a good starting point.

5. In the Process Sleep Duration field, enter in minute, the frequency the housekeeper should optimize text index. For example, if the housekeeper should optimize index every week, enter 10080 (7*24*60) in the field.
6. Click Apply.
7. Return to the housekeeping page.
8. Click Start.

This ongoing housekeeper process wakes up periodically to clean up the Oracle Text index.

Tertiary Storage

Administrators can configure Oracle Email 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 Email is enabled through the housekeeper. The Oracle Email 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 Tertiary Storage Age Threshold 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 Email 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 Email.

Table 3-6 gives the four considerations determining how tertiary storage tablespace should be handled:

Table 3-6 Tertiary Storage Usage and The ESTERSTORE Tablespace

If Tertiary Storage is:	Then The ESTERSTORE Tablespace Should:
Never enabled for the system	Remain empty.
Enabled for Oracle Email	Be set up on a disk different from the primary mail store, either before or after installing Oracle Email.
To be implemented for a new Oracle Email system	Be created on a disk different from the primary mail store, before installation of Oracle Email.
To be implemented for an existing Oracle Email system	Be 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: Chapter 11, "Managing Tablespaces" of the Oracle9i Database Administrator's Guide Release 2 (9.2) for more information on creating and moving tablespaces

Moving the ESTERSTORE Tablespace

Perform the following steps to move the ESTERSTORE tablespace after Oracle Email 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 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: Oracle9i Database Administrator's Guide Release 2 (9.2)

Enabling Tertiary Storage

After the ESTERSTORE tablespace has been created, enable tertiary storage for an instance of Oracle Email housekeeper using the following steps:

1. Using Oracle Enterprise Manager, navigate to the housekeeping page.
2. Create a new Oracle Email housekeeping instance by clicking Create or Create Like.
3. Navigate to the parameter page of newly created housekeeping instance.
4. Set the Tertiary Store parameter to Enable.
5. Disable Pruning and Collection.
6. In the Process Sleep Duration field, enter how often the housekeeper should perform tertiary storage, in minutes.

   For example, if the housekeeping process performs tertiary storage every week, enter 10080 (60*24*7).

7. In the Tertiary Storage 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.

8. Click Apply.
9. Return to the housekeeping page.
10. Click Start.

    The housekeeping server periodically moves messages of the appropriate age into tertiary storage.

Housekeeping Parameters

See Also: Chapter 3, "Servers and Processes" for detailed information on housekeeping parameters

Managing Housekeeping

See Also: "Managing Services and Processes" for instructions on creating, deleting, or setting parameters for housekeeping

List Server Process

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

Users can own and administer public mailing 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 mailing list administrator may screen out advertisements.

The list server is installed with Oracle Email, 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 Max Search Results Entries 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.

See Also: Oracle Internet Directory Administrator's Guide, for more information on setting the MaxSearchResults parameter

APIs provided with the Oracle Email list server enable users to customize lists and messages sent out to a 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 list of all customers who have made purchases in the past three months. Customers on that list can then receive e-mail coupons with discounts based on the amount of their purchases.

List Attributes

List attributes include

• group type, described in Table 3-7
• subscription type, described in Table 3-8
• posting type, described in Table 3-9

Administrators can set or modify these types using the setattribute command described in the List Server Mail Interface section.

A group type is set by the list owner during list creation, and controls list attributes. Examples include what headers go on mail delivered to a list, or whether the list is moderated. The list owner can change the group type after the list is created. Table 3-7 describes the different group types:

Table 3-7 Group Type

Type	Description
announcement	Restricts replies: No auto-replies or DSNs to the mail sent on the list are delivered to the sender Announcements have no Reply-To header. Replies to announcement mail are delivered only to the originator of the announcement.
discussion	Restricts replies to the specific subtopic discussion group on a list: Used when there are multiple discussions occurring on a list. Each e-mail posted has a Reply-To header containing the name of the relevant list. Replies to e-mails sent to this list are sent to the original sender and list. Auto-replies and delivery status notifications (DSNs) are not blocked and are delivered to the sender.
edited	No Reply-To header is set in the mail delivered to the list. Auto-replies or DSNs to the mail sent on the list are not delivered to the sender.
moderated	Restricts postings: only e-mail from those e-mail addresses (moderators) stored in the Group Moderators List attribute is posted. Mail sent to the list is first delivered to all the moderators. Before mail can be posted to the list, at least one moderator must approve the mail within 3 days of the delivery.

Subscription type controls who can subscribe to a list.

Table 3-8 Subscription Type

Type	Description
open	No approval required: any user can subscribe.
restricted	Approval required: subscription requests are sent to the list owner; users are added only if approved.
closed	No approval possible: subscription requests are not received; users are added only if the lister owner invites them.

Table 3-9 describes the list posting type, which can restrict non-members' postings.

Table 3-9 Posting Type

Type	Description
subscriber	Only list subscribers can post a mail to the list. Mail from non-subscribers are rejected.
open	Both subscribers and non-subscribers can post mail to the list.

List Parameters

Table 3-10 describes the list parameters.

Table 3-10 List Server Parameters

Parameter	Description	Acceptable Values	Default Value
Archive Name	Name of the newsgroup archive for this list. Validation is performed in the code to ensure that only valid existing newsgroups are given	Any valid newsgroup name	None
Archiving	If TRUE, messages to this list are archived as a newsgroup in the NNTP server; otherwise not.	TRUE or FALSE
Autoreconfirm	If set to true the subscribe, unsubscribe, suspend, and resume requests must be reconfirmed with the user.	TRUE or FALSE
Create New Archive on News Store	If selected, this option creates the newsgroup in the news store specified.
Editor	List of users (mail IDs) for the editors of the list. Multiple editors can be set with one setattribute command.
External Procedure	Name of the external procedure used to resolve the list, in the following format: schema-name.procedure-name@database-link
Group Approvers	E-mail addresses for the list approvers, who approve subscriptions to a list with Group Subscription Type set to restricted. If an approver is set, all subscriptions to the list must be approved by the approver and not the list owner. A list owner can also be an approver. Any approver can approve a subscription request.
Group Auto Reconfirm	If TRUE, requests to subscribe, unsubscribe, suspend, resume or invite must be reconfirmed with the user.
Group Has Archive	If TRUE, the list is archived, and all messages are addressed to the list are archived.	TRUE or FALSE	FALSE
Group Information Text	Multi-line owner-provided descriptive text about the list
Group is External	If TRUE, the list is resolved externally; otherwise locally.	TRUE or FALSE	FALSE
Group Merge Tag	A tag used for specifying mail merge and scheduler tags, enabling a list owner to support mail merge or scheduled mail delivery
Invitetext	Multi-line text sent in e-mail to users invited by a list owner to join the list. When setting this parameter through the setattribute command, the parameter value should be enclosed within quotations
List State	State of the list, active or inactive: active - posting is permitted inactive - the list is not recognized as a recipient, no posting is permitted migrating - the list is being migrated into this Oracle Collaboration Suite installation	active, inactive, migrating	active
Mail Store	If specified, the mail store on which the messages addressed to this list are queued until the list server processes them. If not, then messages addressed to this list is queued wherever they are received.
Moderator	List of users (mail IDs) who are the moderators of the list Owner List owner Post, Open or Subscriber. If SUBSCRIBER, then only subscribers to the list can post messages to the list; otherwise anyone can.
Subscription	Type of subscription control placed on the list, one of the three shown Open, Restricted, or Closed.
Topic	Single-line phrase describing the topic of discussions on this list, enclosed within quotes
Type	Type of the list, one of the following four: Announcement, Discussion, Edited, or Moderated
Unsubscribe Not Allowed	If TRUE, allows only the list owner to unsubscribe a member from a list. If FALSE, anyone can unsubscribe.	TRUE or FALSE	FALSE
Use Existing Archive	Names an existing newsgroup as the list archive

List Server Mail Interface

The email list server performs certain tasks when it receives commands by e-mail from administrators or users. The setattribute command is used by administrators to set values for various list parameters. For example, if John, the list owner of [e-mail] wants to set the list type to moderated, he would have to send an e-mail to the list administrator with the e-mail body containing the following line:

setattribute type=moderated

Syntax

setattribute type=list type subscription=subscription type topic="list topic" 
autoreconfirm=true/false post=post type editor=editor mailid moderator=moderator 
mailid invitetext="multi-line text" 

Archiving Lists

Note: To enable list archiving, the NNTP server must be configured and running.

A list owner can have all e-mails sent to a 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 list in order to archive messages.

When a list is archived, a newsgroup is created with a name reflecting the original list. For example, the name of the NNTP archive newsgroup for the list [e-mail] becomes the following:

ListArchive.abc

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

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

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

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

External Lists

External lists provide a way for the membership of a list to be stored outside of Oracle Collaboration Suite, while using the list server to deliver e-mails to such a list. A list owner or domain administrator can configure a list to be external by checking the external list option in the list properties page. A PL/SQL procedure for resolving the addresses of the list members must be created on the mail store the list server is connected to. If the PL/SQL procedure is on a different database, then a database link must be created from the mail store to the other database.

The PL/SQL procedure must have the following syntax:

procname(listid IN VARCHAR2,
return_count IN NUMBER,
count OUT NUMBER,
recipients OUT TABLE OF VARCHAR2(2000))

The list server calls the procedure two times while resolving an external list:

The first value passed for the return_count parameter is 1. It receives in return the count out parameter, containing just the number of recipients in the list, and not the list of recipient addresses.

The second value passed for the return_count parameter is 0, causing the procedure to return a table of varchar2(2000) in the recipient 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. Using the Oracle Collaboration Suite administration pages, login as domain administrator.
2. Navigate to the list [e-mail].
3. Edit the properties of the list.
4. Select true in the list box for the Group Is External field.
5. Set the External procedure parameter to get_cust_list.
6. Connect as es_mail to the mail store the list server is connected to create the following PL/SQL procedure:

   CREATE OR REPLACE PROCEDURE get_cust_list(listid IN VARCHAR2,
   return_count_flag IN NUMBER,
   cnt OUT NUMBER,
   recipients OUT dbms_sql.varchar2_table)
   as
   begin
   if (return_count_flag = 1) then
   -- when this procedure is called with the value of the second parameter as 
   -- 1, it is expected to return the total number of users in the list in the 
   third
   -- parameter
   select count(*) into cnt from customer_list;
   else
   -- when this procedure is called with the value of the second parameter as
   -- anything other than 1, it is expected to return the recipients in the
   -- external list in the fourth parameter with each recipient in one row
   -- of the output varchar2 table
   select customer_mail
   bulk collect into recipients
   from customer_mail;
   end if;
   end;
   
   

The previous example assumes that [e-mail] is a list of customers maintained in a database table by a different application. This procedure uses a table customer_list described in Table 3-11.

Table 3-11 cust_list

Column Name	Data Type	Explanation
customer_mail	varchar2 (1000)	Mail ID of a customer

Assuming that the table customer_list is populated with email addresses, sending a mail to the list [e-mail] using an Oracle Email SMTP server delivers the mail to all the recipients in the customer_list table.

Mail Merge

Mail merge enables customized mail to be delivered to every list recipient. List owners or domain administrators must decide on a mail merge tag for a list and set it in the list properties page. The mail merge tag can be a single word or a group of words. This feature can be enabled for a list by providing a value for the merge tag property of the list. Table lists the two types of mail merge that the list server supports.

Table 3-12 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 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>. 
    ... 

By default, the list server looks for the PL/SQL function in the mail store that the server is connected to. If the function is on a different database, a database link must be created to that database in the ES_MAIL schema, and that link must be referenced in the mail merge tag. For example, if the getSalary function is defined in a different database and you've created a database link called dblink, your mail merge message would need to look like the following:

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

Example

Note: The following example assumes that lists and users have been setup correctly with the list server process configured and running.

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

1. Using the Oracle Collaboration Suite administration pages, log in as domain administrator.
2. Navigate to the list [e-mail].
3. Edit the properties of the list and set the Group merge tag parameter to mail merge.
4. 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-13 lists the columns contained in the emp_payroll table in the previous example.

Table 3-13 emp_payroll

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

Send a message with mail merge tags embedded in it. This sends a mail to each recipient in the list [e-mail] with his/her 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 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 list. Specify the delivery time for a message by putting the schedule mail delivery tag anywhere in the mail. The following example shows how, using orcl as the tag for the mail merge property of the 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 mandatory.

Table 3-14 send_schedule

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.

Managing Lists

Using Oracle Webmail, you can

• create, delete, or show lists or list members,
• modify list properties, and
• show all the lists a member is on.

Creating Lists

To create a list, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Distribution List Management > Create a new list.
3. Select the domain from the drop down list.
4. Select SMTP or List Server from the Distribution List Type drop down list. The distribution list type defines the mailing list type.
5. Click Go.
6. Enter the following information in the corresponding fields.
   • Distribution List Name
   • Owner
   • Maximum Message Size
   • Group Topic
   • Group Invite Text
   • Group Editor's List
   • Group Moderator's List
   • Group Merge Tag
   • Group Auto Reconfirm
   • Group Type
   • Group Subscription Type
   • Group Post Type
   • Group Approvers list
7. Click Create.

Modifying List Properties

To edit list properties, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Distribution List Management > Edit list properties.
3. Enter the list name, or enter * to display all available lists.
4. Select the domain of the list from the drop down list.
5. Select the list you want to make changes to.
6. Edit the properties you want to change.
7. Click Modify.

Modifying Default New List Attributes

To modify domain preferences for lists, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select Domain > Default New List.
3. Select the installation from the drop down list.
4. Select the domain you want to modify.
5. Click Submit.
6. Modify the attributes you want to change.
7. Click Submit to commit the changes or Cancel to return to the previous page.

Deleting Lists

Perform the following steps to delete a list:

To delete a list, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Distribution List Management > Delete list(s).
3. Enter the list name, or enter * to display all available lists.
4. Select the domain of the list from the drop down list.
5. Click Go.
6. Select the list you want to delete.
7. Click Delete.

Showing Lists

To view all lists in a particular domain, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Distribution List Management > Show list(s).
3. Enter the list name, or enter * to display all available lists.
4. Select the domain of the list from the drop down list.
5. Click Go.
6. Select the list you want to view.

Showing Members

To show list members, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Membership Management > Show Members.
3. Enter the list name, or enter * to display all available lists.
4. Select the domain of the list from the drop down list.
5. Click Go.
6. Select the list for which you want to view members.

Adding and Deleting List Members

To add or delete list members, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Membership Management > Add/Remove Members.
3. Enter the list name, or enter * to display all available lists.
4. Select the domain of the list from the drop down list.
5. Click Go.
6. Select the list for which you want to add members.
7. Enter or remove information in the following fields:
   • Members (user) - Users on this system that are members of this list
   • Members (list) - Lists that are members of this sub-list
   • Members (alias) - Aliases that are members of this list
   • Members (foreign) - Users foreign to this system who are members of this list
8. Click Modify.

Showing All the List a User is On

To show all the lists subscribed to by a user, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select List > Miscellaneous Functions > Show all memberships of a user.
3. Enter the user's name.
4. Select the user's domain from the drop down list.
5. Click Show Memberships.

List Server Parameters

See Also: Chapter 3, "Servers and Processes" for detailed information on list server parameters

Managing List Servers

See Also: "Managing Services and Processes" for instructions on creating, deleting, or setting parameters for list servers

NNTP Server Process

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 Email NNTP server can be used out of the box. In addition, the NNTP server uses the standard mail store 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 Email NNTP server parameters, which administrators can modify to meet performance or feature requirements of their site.

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 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.

Storage Requirements

News articles are stored in a standard Oracle Collaboration Suite mail store. Inbound and outbound servers connected to a mail store only handle newsgroups created in that mail store. News articles are automatically expired strictly by the housekeeping 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 housekeeping 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 mail store access is needed. Caching can only be done for articles less than 4 kilobytes 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.

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 Peer Server Parameters.

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.

Peer Server Parameters

Table 3-15 describes the peer server parameters in alphabetical order.

Table 3-15 Peer Server Parameters

Parameter	Description	Acceptable Values	Default Value
Host Name	Internet host name of the peer, used by NNTP Inbound to recognize an incoming connection as a peer connection	Canonical host name of the peer as returned by DNS	None
Inbound Feed Accepted Newsgroups(s)	Names of newsgroups for which feed is accepted from this peer. If any groups are specified, then messages are accepted only if addressed to one or more of them.	Multi-value newsgroup names. Wildcards are allowed	None
Inbound Feed Rejected Newsgroups(s)	Names of newsgroups for which feed is rejected from this peer. If any groups are specified, then messages are rejected if addressed to one or more of them. This is checked after Inbound Feed Accepted Newsgroups(s). If a newsgroup appears in both accepted newsgroups and rejected newsgroups, it is rejected.	Multi-value newsgroup names. Wildcards are allowed	None
Installation	The Oracle Collaboration Suite installation for which this peer is to be configured	An installation in which newsgroups have been created, and NNTP server has been configured	um_system
Outbound Feed Newgroups	Names of newsgroups for which feed is offered to this peer. If any groups are specified, then only messages posted to any of these groups are offered.	Multi-value newsgroup names. Wildcards are not allowed.	None
Port	NNTP port on which the peer listens, used by NNTP Outbound to connect to the peer	None	119

Managing Peer Servers

You can use Oracle Webmail to add, edit, or delete peer servers, as the following sections describe.

Adding Peer Servers

To add a peer server, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Peer Server Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Click Add.
6. Enter information in the appropriate fields.
7. Click Submit to commit the changes or Cancel to return to the previous page.

Editing Peer Server Properties

To edit a peer server, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Peer Server Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the peer server for which you want to edit properties.
6. Click Edit.
7. Edit the properties you want to change.
8. Click Submit to commit the changes or Cancel to return to the previous page.

Deleting Peer Servers

To delete a peer server, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Peer Server Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the peer server you want to delete.
6. Click Delete.

NNTP Server Parameters

See Also: Chapter 8, "Parameters and Log Files" for detailed information on NNTP server parameters

Managing NNTP Servers

See Also: "Managing Services and Processes" for instructions on creating, deleting, or setting parameters for NNTP servers

About Newsgroups

Note: Newsgroups cannot be used in Oracle Webmail.

A newsgroup is a collection of messages discussing a particular subject, posted to an internet site and redistributed through Usenet, a worldwide network of news discussion groups. There are two types of newsgroups, public and private:

• Public newsgroups have worldwide distribution, are maintained at many news sites, and are intended to contain non-sensitive information. The NNTP service exchanges newsgroup articles among news sites.
• If your Oracle Collaboration Suite installation hosts more than one domain, public newsgroups are shared, which greatly reduces the storage space required for news articles. An inbound server always services all public newsgroups configured for an Oracle Collaboration Suite installation.
• Private newsgroups belong to and are visible in only one domain, where they are intended as internal discussion groups. Access to private newsgroups is permitted only if the inbound server has the local domain parameter set to that domain. An inbound server instance cannot host private newsgroups for more than one domain. For example, an inbound server instance with the local domain set to acme.com serves all public newsgroups in addition to only those private newsgroups that belong to the acme.com domain.

Newsgroups are organized into subject hierarchy. The first few letters of the newsgroup name indicates the major subject category; sub-categories are represented by a subtopic name. Users can post to existing newsgroups, respond to previous posts, and create new newsgroups. Some newsgroups have a moderator, a designated person who decides which postings to allow or to remove.

Three attributes are associated with newsgroups:

• Name
• Description
• Posting allowed

Newsgroup Parameters

Table 3-16 describes the newsgroup parameters in alphabetical order.

Table 3-16 Newsgroup Parameters

Parameter	Description	Acceptable Values	Default Value
Article Retention Day(s)	Number of days articles are stored	Number of days	None
Description	Brief description of the newsgroup	A single line of text	None
Mail Store	Mail store of the newsgroup	The mail store where the newsgroup was created	NULL
Moderated Newsgroup	If YES, this newsgroup is moderated; otherwise not.	YES or NO	NO
Moderator(s)	E-mail addresses of the moderators	Valid e-mail addresses of the moderators	None
Newsgroup Name	Name of the newsgroup	Only 7-bit English ASCII characters are allowed	None
Owner	Name of the newsgroup owner	A valid e-mail address of the group owner	None

Managing Newsgroups

You can use the Oracle Webmail client to add, edit, or delete private and public newsgroups.

Adding Private Newsgroups

To add a private newsgroup, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Private Newsgroup Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Click Add.
6. Enter information in the appropriate fields.
7. Click Submit to commit the changes or Cancel to return to the previous page.

Editing Private Newsgroup Properties

To edit a private newsgroup, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Private Newsgroup Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the private newsgroup.
6. Click Edit.
7. Edit the properties you want to change.
8. Click Submit to commit the changes or Cancel to return to the previous page.

Deleting Private Newsgroups

To delete a private newsgroup, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Public Newsgroup Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the private newsgroup.
6. Click Delete.

Adding Public Newsgroups

To add a public newsgroup, perform the following steps:

1. Select News > Public Newsgroup Management.
2. Select the installation from the drop down list.
3. Click Go.
4. Click Add.
5. Enter information in the appropriate fields.
6. Click Submit to commit the changes or Cancel to return to the previous page.

Editing Public Newsgroup Properties

To edit a public newsgroup, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Public Newsgroup Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the public newsgroup.
6. Click Edit.
7. Edit the properties you want to change.
8. Click Submit to commit the changes or Revert to return to the original settings.

Deleting Public Newsgroups

To delete a public newsgroup, perform the following steps:

1. Navigate to the Oracle Webmail client administration page.
2. Select News > Public Newsgroup Management.
3. Select the installation from the drop down list.
4. Click Go.
5. Select the public newsgroup.
6. Click Delete.