Oracle Email Administrator's Guide Release 9.0.3 Part Number B10033-01 |
|
| View PDF |
This chapter discusses the different servers and processes of the Oracle Email system.
This chapter contains the following topics:
The Oracle Email mail store is the location where messages and folder information are stored. If a message is destined for many accounts on that mail store, only one copy of the message is stored and links to the message are sent to all recipients. Folders can be private, shared, or public. A single mail store can store mail for one domain or several different domains. If you have an extremely large domain, it is possible to have multiple mail stores support a single domain.
Applications can make direct PL/SQL procedure calls to act upon messages similar to the voice mail client use standard protocol servers or JMA+ libraries. Calls made to the stored procedures are executed in the mail store.
The mail store loads stored procedures that enable the following features:
The Oracle Email mail store has a comprehensive and high-level PL/SQL interface. Clients make high-level calls to the mail store.
Because the logic of the PL/SQL procedures take place inside the Oracle9i database mail store, close to the actual data, mail transactions are greatly simplified and more reliable. Oracle Email, by definition, enables multiple clients and client types to access the same mail store. By having all clients enter through the same interface and perform processing in the mail store, all clients achieve the same goals with the same behavior.
For example, a typical Oracle Email installation enables a user to listen to voice mail messages from any one of three clients:
In a typical telephone situation, if a voice mail message has not been heard, the Message Waiting Indicator (MWI) light on the user's telephone is on. If all voice mail messages have already been listened to, the light is off. Because the MWI logic is placed inside the mail store and not in the Web client, standard client, or telephone handset, the solution consistently and appropriately turns the light off no matter which client was used to listen to the voice mail messages.
All of the Oracle Email scalable protocol servers and access servers perform tasks within the stored PL/SQL procedures running within the mail store. One can query an entire mail store with a simple request and the mail store efficiently carries it out. This comprehensive high-level interface enables effective support for system-wide rules, individual rules, server side filters, and spam control, for a very large and dynamic mail store without serious degradation. It also affords Oracle Email the ability to query and update the mail store efficiently.
The mail store can be extended by or integrated with other Oracle product capabilities. Filters can be applied that automatically act on all mail messages. The filters can either perform common mail tasks on a mail message, or they can pass the mail message to an external program.
For example, an Oracle Email e-mail server can be set up to filter all mail messages sent to the abstract Helpdesk mail account of a company. Each message is broken down into its main body and any attachments. Each part is then passed, individually, through the Oracle Text engine. The results can then be routed to the appropriate support representative, who can choose from a list of possible responses to the specific request or create and log a new response.
See Also: :
Chapter 2, "Getting Started" for more information on how to install a mail store |
Using Oracle Enterprise Manager, perform the following steps to modify mail store default parameters:
Using Oracle Enterprise Manager, perform the following steps to modify mail store default parameters:
The following is a list of mail store parameters.
Connections idle for more than this time value are terminated, to maintain an optimum number of open connections
Oracle Email can increase the number of connections to be opened to the database bye this number, if the current number of connections are less than maximum. Valid values are 0 and above.
Specifies the minimum number of connections in the connection pool. Valid values are 0 and above.
Specifies the maximum number of connections that can be opened to the database. Once this value is reached, no more connections are opened. Valid values are 1 and above.
The machine on which the database is located.
Port number the database listener is listening on.
System identifier of the mail store database.
The user name used to log into the mail store database as the mail user.
The password for the mail store user name.
The integration of Oracle Text and Oracle Email extends the e-mail server functionalities. This enables 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.
There are two user level Oracle Internet Directory parameters associated with the configuration of Oracle Text:
The following table describes the parameter values for orclMailUserIndexType and orclMailIsDocBinary
The parameters are independent of each other, and can be configured at the user level. The parameters are present at the domain level preferences for viewers. The values set here are inherited by all new users in the domain during user creation time. 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.
There are two quota values that can be set for a user: user-quota and voice-quota. All e-mails and voice mails are delivered to the user as long as the user is under user-quota. When user-quota is reached, all e-mails are held in the system and are not delivered to the user. However, voice mail delivery continues as long as the user's total usage is under user-quota plus voice-quota value. For example, if the user-quota is 50MB and the voice-quota is 20MB, e-mail delivery stops after the user's usage is 50MB but the voice mail delivery continue until the user reaches 70MB.
When the user cleans up the account and the usage is under the user-quota plus voice-quota value, voice mail delivery starts again. When the usage is under user-quota, e-mail delivery starts again. It is important to note that both e-mails and voice mails contribute to the user-quota calculations. When the usage reaches the user-quota, it means that the sum of e-mails and voice mails is equal to the user-quota value. Voice-quota is an additional buffer provided to users so that voice mail delivery is not affected when users reach their quota.
In addition to stopped mail delivery, users cannot save new messages in the server folders when user-quota is reached. For example, saving a copy of outgoing messages to the sent folder is not allowed. The IMAP server informs the client that the user is over quota and is trying to save new mail.
Server side filters enable users to create mailbox filters on the server. Users can use the Thin Client to create rule-based actions, such as message foldering, vacation reply, spam filter, and wireless notification. Because the filters are created on the server, the actions are carried out whether the user is online or not.
The filters engine enables customized auto-actions on e-mail messages being processed, based on a variety of customizable events and conditions.
The filters engine is an automated layer between server processes and message objects. It provides scripted operations done on behalf of the server processes to the message objects. The filters engine maintains its script database in the mail store.
Internet Message Access Protocol (IMAP) and Post Office Protocol (POP), are protocols for retrieving e-mail messages.
The POP3 protocol provides mail manipulation services for certain types of smaller nodes on the Internet where it is often impractical to maintain a message transport system, or in situations where it is 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.
The IMAP4 protocol provides a set of functionality to manipulate mail messages as well as mail folders, which are stored on the server. It provides primitives to allow optimization of online performance, especially when dealing with large MIME messages. The IMAP4 protocol also provides the capability for an off-line client to re-synchronize with the server.
The IMAP4 and POP3 servers support the IMAP4 and POP3 protocols as described in the RFC-2060 and RFC-1939 respectively.
See Also:
www.ietf.org for more information on RFCs |
The IMAP4 Server also supports the following IMAP4 extensions:
By using the scalable protocol server programming framework, the IMAP4 and POP3 Servers obtain the benefits of multithreading, database connection sharing, and load balancing, which enables the servers to support thousands of concurrent user connections.
The IMAP4 and POP3 support a large number of client connections, using a very small amount of system resources for each client connection. It maintains a pool of worker threads, which handles the work for the clients and also a pool of database connections shared across client connections. When a client request comes in, a thread from the pool of worker threads is assigned to it. The worker threads read the command from the client, obtain a database connection from the database pool, and perform the operation. After the database connection is released back to the pool, the thread returns to the worker thread pool. There can be multiple mail stores in the system. The IMAP4 and POP3 servers can be set up to create database connection pools to more than one mail store. Administrators should check the IMAP4 and POP3 server parameters on how to control the size of the pools.
Many operating systems have limitations on the number of file descriptors and sockets a single process can open, requiring more than one instance of an IMAP4 or POP3 server to be running. If there is more than one instance running on the server, the listener distributes the load between them. Administrators should verify that the operating system parameter controlling the file descriptors for a process is correctly set.
Text description of the illustration iumag001.gif
The IMAP4 logs are written in $ORACLE_HOME/oes/log/<install_name>/imap/<pid>/<pid>.log. Different log levels determine the amount of information produced by from the servers. There are five different log levels. Their names and values from least to most are:
Error Level | Numeric Value |
Internal Errors |
1 |
Errors |
6 |
Warnings |
11 |
Notification |
16 |
Trace |
21 |
Dump |
26 |
Simple Mail Transfer Protocol (SMTP), is a protocol for sending e-mail messages between servers. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another; the messages can be retrieved with an e-mail client using either POP or IMAP. Mail clients generally use SMTP to send messages to a mail server.
The SMTP server handles all inbound and outbound mail. It implements the SMTP protocol and interacts with DNS and Oracle Internet Directory servers to get information about hosts and users.
The following is a list of the SMTP server -supported RFCs.
See Also:
www.ietf.org for more information on RFCs. |
RFC 821 - Simple Mail Transfer Protocol (SMTP)
RFC 1123 - Requirements for Internet hosts - application and support
RFC 1869 - SMTP Service Extensions
RFC 1652 - SMTP Service Extension for 8bit-MIME transport
RFC 1870 - SMTP Service Extension for Message Size Declaration
RFC 1891 - SMTP Service Extension for Delivery Status Notifications
RFC 1894 - An Extensible Message Format for Delivery Status Notifications (DSNs)
RFC 2034 - SMTP Service Extension for Returning Enhanced Error Codes
RFC 822 - Standard for the format of ARPA Internet text messages
RFC 2045 - MIME Part 1: Format of Internet Message Bodies
RFC 2046 - MIME Part 2: Media Types
RFC 2047 - MIME Part 3: Message Header Extensions for Non-ASCII Text
RFC 2048 - MIME Part 4: Registration Procedures
RFC 2049 - MIME Part 5: Conformance Criteria and Examples
Oracle Email has a flexible architecture that enables users to set up a single, double, or multiple tier configuration that is appropriate to a site's needs. The following are examples of various configurations.
Text description of the illustration iumag002.gif
Figure 4-2 is the simplest setup where there is only one mail store and SMTP server running on the same host. This configuration can be used for supporting a small numbers of users.
Text description of the illustration iumag003.gif
Figure 4-3 is a single mail store setup, with the processes divided into two tiers: the backend running the database and the middle tier running SMTP and other protocol servers. It provides fault tolerance and the flexibility to run multiple SMTP servers and distribute load across them. Load balancing and fault tolerance can be achieved by running the servers behind a network director or by having multiple MX records for the domain.
Text description of the illustration iumag004.gif
Figure 4-4 shows two kinds of configurations: multiple mail stores on different hosts and multiple mail stores on the same host. Each SMTP server serves only one mail host and each mail store must have a SMTP server. The mail stores on the SMTP hosts are used as SMTP queues and do not contain users.
The SMTP message transfer agent engine is responsible for the incoming SMTP connection. It receives incoming messages and performs address lookup and rewriting. The Oracle Internet Directory server is queried to find and authenticate the addresses. Addresses are rewritten based on the rewriting rules. Anti-spamming rules is applied. If all of the above 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. To determine if an address is local, the parameter SMTPlocaldomains is used. This parameter contains the list of domains that are considered local. The local delivery module picks up the message later, applies the rules, if any, and delivers it to the user's inbox.
If administrators do not want to process the messages immediately for performance reasons, messages can be stored in the submission queue and marked as submitted or unprocessed. This is controlled by the server parameters. Messages created by the SDK applications are also marked as submitted in this situation.
The messages in the submission queue are picked up by the outbound queue processor. For relay messages, the outbound processor queries the DNS server, applies the rules against them, and sends them out using SMTP. The submitted messages first go through the Address Rewriting and DNS resolution module. After which, the outbound queue processor sends them to the local delivery queue or to the Internet, depending on whether the messages' recipients are local or not.
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 message is for a user on a different mail store, then the message is placed in the relay queue. The outbound server picks up the message and transfers the mail to the other mail store using the SMTP protocol.
The Oracle Net listener listens on the SMTP port, default 25, and transfers connections to the SMTP server. The SMTP server maintains a pool of worker threads and two other pools: a database connection pool to the mail store and a pool of connections to the Oracle Internet Directory server. Upon receipt of a new client connection, a thread is picked up from the pool to handle the request. It performs name resolution using a connection from the Oracle Internet Directory pool and then inserts the mail into the database using a connection from the database pool. At this point the SMTP connection to the client is terminated, but if there are local recipients, the worker thread continues to process the mail and performs local delivery.
Text description of the illustration iumag005.gif
The outbound STMP server has three main threads for each queue: submission, local, and relay. Each of the threads poll the database for messages in its queue. Whenever there are messages to process, a new thread is spawned to process the mail.
The SMTP server also maintains two other pools: a database connection pool to the mail store and a pool of connections to the Oracle Internet Directory server. When a thread is started to process a mail, 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 db session is returned back to the pool.
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.
Text description of the illustration iumag006.gif
The SMTP server supports a variety of anti-spam methods to prevent users and domains from spamming and to prevent the server from being used as relay for other domains. The various spam prevention methods are:
The SMTP MTA supports virus scanning software from Symantec. Symantec's CarrierScan Server provides a native TCP/IP protocol to communicate with the client. Oracle Email provides a client program that can send the messages to the Symantec server and read the results of the scan. The MTA spawns this client program through the external filter process and pass the messages to it. The MTA delivery module verifies the returned value and decides whether to accept the message, or to reject the message and issue a DSN.
The LDAP parameter orclMailSmtpExternalFilter of the SMTP server must be set to TRUE, and orclMailSmtpExternalFilterProcess must be set to the name of the client program. When the local delivery module processes a message, it spawns the client program and passes the message to the new process. The client process communicates with the Symantec server using the native TCP/IP protocol. The client sends the protocol version, request and the message. The server reply consists of a reply code, scan results, and the modified message.
The local delivery module verifies the return value and decides whether to accept the message, or to reject the message. If there are any errors, the MTA rejects the message and send back a DSN.
In the $ORACLE_HOME/oes/admin/ directory, create a file for the Symatec server in the following format named symantec.cfg:
<host ip> <port>
Name | Description |
---|---|
host ip |
The IP address of the host running the Symantec server. |
port |
The port the Symantec server listens on. |
SCSCANFILE_INF_NO_REP (-3) SCSCANFILE_INF_PARTIAL_REP (-2) SCSCANFILE_INF_REPAIRED (-1) SCSCANFILE_CLEAN (0) SCSCANFILE_FAIL_CONNECT (1) SCSCANFILE_FAIL_INPUTFILE (2) SCSCANFILE_FAIL_ABORTED (3) SCSCANFILE_INVALID_PARAM (4) SCSCANFILE_FAIL_RECV_FILE (5) SCSCANFILE_FAIL_MEMORY (6) SCSCANFILE_FAIL_FILE_ACCESS (7)
After a message is inserted into the database and before it is delivered, an external process can be used to filter the mail. An example of this is an virus scanner that can be invoked to scan the messages and reject messages that are infected. The external process returns a true or false indicating whether to accept or reject the mail. It is controlled by the following server parameters:
An address rewriting rule can have the following attributes:
Address rewriting rules contain symbols that determine how an address is parsed and how it is changed.
Address renaming rules are applied sequentially, starting with Rule 1. All rules are applied, unless a result starts with $@, that stops rule execution immediately 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 application of the rule yields no more 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 such as an alias, 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 yields no more changes, the rule execution process is done.
Housekeeping is a standalone component that directly interacts with the mail store database. It is a background process performing cleanup tasks that can be set to run according to a schedule. During Oracle Email installation, a housekeeping job is created by default and has a default configuration associated with it. Administrators can manually alter its schedule or add more instances of the job.
Job scheduling and management are taken care of by Oracle Enterprise Manager. During the time a housekeeping process is running, it responds to administrative requests such as reporting job progress, reinitializing job parameters, or shutting down.
See Also:
Oracle Enterprise Manager Administrator's Guide for more information on job scheduling |
Other servers interact with housekeeping by producing garbage. There are primarily three types of garbage - producing agents:
Housekeeping performs tasks in multiple stages, with some stage of operations producing garbage for another stage. For example, when performing message expiration stage, the housekeeping process produces messages that are later consumed by the pruning stage.
SMTP server creates and processes messages that are mostly in transit. The messages stay in queues until the SMTP server finishes processing them. The processed messages are marked as processed, sent to the housekeeping process, and removed from the system. When users delete messages through clients, the messages are marked for deletion and are picked up by housekeeping process for actual deletion.
The housekeeping log files are located in two areas: the mail store and the middle tier. The log file on the mail store contains information on the progress of housekeeping tasks, the log file on the middle tier contains information on the status of the process.
Mail boxes are dynamic in nature. Mail constantly enters the store and is processed and deleted. Oracle Email housekeeping cleans up deleted messages and can be set to move old and rarely read mail messages to a tertiary tablespace.
The process of moving old messages to a tertiary tablespace is called tertiary storage. It enables administrators to move older messages to larger and less expensive disks according to a configurable age threshold. This process frees up valuable space on the primary disk to hold more recent and frequently accessed messages.
See Also:
for information on how to configure Oracle Email housekeeping server to perform tertiary storage |
List servers provide a means of public list management as well as integration with other messaging services or applications.
The Oracle Email list server enables users to own and administer public mailing lists. The lists can be set up as a means of distributing information to groups of people or as a discussion forum. In addition, lists can be set up with restricted membership, where users must be approved before becoming a member. Lists can also be set up so that any messages sent out are moderated, where only certain members can send out messages. For example, the administrator of a mailing list may screen out advertisements.
When a distribution list has a large number of members, the Oracle Internet Directory Max Search ResultsEntries parameter must be configured to return a large number of entries to enable the list resolution API to return all the members. The Oracle Internet Directory Max Search ResultsEntries parameter can be configured through oidadmin.
APIs provided with the Oracle Email list server enable users to customize lists and messages sent out to a list. The Oracle Email list server features can be used for applications such as marketing campaigns where special non-transferable offers are sent and readable only by the intended recipients. For example, a user can use the list server APIs to query a database of sales information to create a list of all customers who have made purchases in the past three months, then send coupons by e-mail to each of the customers with discounts based on the amount of their purchases.
The list server mail interface command is a list of commands that administrators and users can send to the list server to perform certain tasks. The setattribute command is used by administrators to set values for various list parameters.
See Also::
Oracle Collaboration Suite User's Guide for more information on list server mail interface commands for users. |
Use this command to set values for the various parameters of the lists by an administrator.
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>"
Although none of the parameters are mandatory, every setattribute command should have at least one parameter. The following is a list parameters and their definitions:
The list server supports mail merge and scheduled mail delivery. This feature can be enabled for a list by providing a value for the merge tag property of the list.
Mail merge: Enables customized mail to be delivered to every list recipient. The list server supports two types of mail-merge:
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)
To use this feature, use the mail merge tag in the appropriate sections 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 example, if you have a PL/SQL getsalary function that returns the salary of an individual given his mail address, you can send a mail 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 ES_MAIL schema and use that in the mail-merge tag. For example, the getSalary function is defined in a different database, create a database link called dblink. The mail will now look like this:
Dear <orcl>recipient_full_name</orcl>, Your salary is <orcl>getSalary(recipient_mail_address)@dblink</orcl>. ...
This feature can be used to schedule mail delivery to a list at a particular time. This feature can be enabled by providing a value for the mail merge property of the list. In the mail, specify the delivery time of the mail by putting in the schedule mail delivery tag anywhere in the mail. The following is an example of how the tag appears if the mail merge property of the list is orcl.
<orcl>send_schedule=DD-MON-YYYY hh24:mi [TZH:TZM]</orcl>
If TZH and TZM are not specified, the list server uses the sender's time zone to schedule delivery of the mail.
This section discusses how to start, stop, reinitialize, and modify server processes.
Starting an Oracle Email process starts all the processes comprising that service type, such as IMAP and POP.
Stopping an Oracle Email system sends a request to the operating system to shut down all of the Oracle Email processes. A reason and administrator would want to stop the Oracle Email system is to perform maintenance, such as upgrading the server hardware or software. It is not possible for the processes to be running while certain kinds of upgrades are performed.
Reinitializing an Oracle Email process informs the operating system to reload its operational settings from the Oracle Internet Directory server. The process does not stop running, which means that users continue to receive uninterrupted service. Whenever a Oracle Email process parameter is modified, it must be reinitialized to make the changes take effect.
Note: The following functions can only be executed if at least one instance has been created. |
Using Oracle Enterprise Manager, perform the following steps to start, stop, or reinitialize all server processes:
Using Oracle Enterprise Manager, perform the following steps to create a server instance:
To create a new IMAP4 server instance with default parameters:
To create a new server instance with the same parameter values as an existing server instance:
Warning: Deleting an Oracle Email process may disable some or all e-mail processes. |
Using Oracle Enterprise Manager, perform the following steps to delete a server instance:
Note: A process must be shut down before it can be deleted. |
Using Oracle Enterprise Manager, perform the following steps to start a server instance:
Using Oracle Enterprise Manager, perform the following steps to stop a server instance:
Note: Servers must be reinitialized whenever parameters are modified. |
Using Oracle Enterprise Manager, perform the following steps to reinitialize a server instance:
Note: reinitializing does not interrupt user actions because the service is not brought down. |
Note: Servers must be reinitialized whenever parameters are modified. |
Using Oracle Enterprise Manager, perform the following steps to modify parameters for a specific server instance:
To make the changes take effect, you must reinitialize the server instance.
Note: Servers must be reinitialized whenever parameters are modified. |
Using Oracle Enterprise Manager, perform the following steps to modify server default parameters:
To make the changes take effect, you must reinitialize the server.
This section provides parameter definitions for the different servers.
The following is a list of IMAP4 server parameters and their definitions:
This parameter specifies the number of Oracle Internet Directory connections the pool is increased by.
This parameter specifies the minimum number of Oracle Internet Directory connections in the pool.
This parameter specifies the maximum number of Oracle Internet Directory connections in the pool.
This parameter specifies the time lag (1/100th of a second) permitted before increasing the pool. For example, if the time lag value is 100 it means 1 second. This indicates that if the concurrent connections arrive within 1 second then the server must wait.
This parameter specifies the maximum time in seconds the server has to wait to get a connection after it has reached the maximum number of connections.
This parameter specifies the time after which the server tries to reconnect to Oracle Internet Directory.
This parameter specifies the total number of times the server attempts to connect to Oracle Internet Directory.
This parameter specifies the number of threads the client connection pool is increased by.
This parameter specifies the number of seconds after which an idle thread is cleaned up.
This parameter specifies the minimum number of threads available for client connection handling.
This parameter specifies the maximum number of threads available for client connection handling.
This parameter determines which port the listener is listening for the IMAP service. Selecting Custom enables administrators to specify their own presentation name.
This parameter applies on if the presentation name is set to custom.
This parameter applies if the presentation name is set to custom.
This parameter specifies the log messages level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
Range: 4294967295 (32bits, multi-value)
This parameter specifies the default domain for user login. If the user does not provide a domain when logging in, the value of this parameter is used.
This parameter specifies the maximum number of clients allowed to connect to the server instance.
This parameter specifies the maximum number of times a nesting rule can be applied to a message. In general, setting this parameter to a smaller number increases overall performance, but not for systems that use rules heavily.
This parameter specifies the caching level. For small caching levels, no mail information is cached in the middle tier IMAP server. For medium caching levels, certain parts of mail are cached. Increasing the cache size increases the memory requirements on the middle tier.
This parameter specifies the interval to wait before checking for new mail. The IMAP server does not check for new mail until the time interval has elapsed. If clients send a large number of check new mail requests to the server it affects performance.
Auto-logout timeout interval. If a client does not perform any operations within this interval, it is disconnected.
This parameter enables administrators to select a user name to obtain more debug information in the log files for that user.
The following is a list of POP3 server parameters and their definitions:
This parameter specifies the number of Oracle Internet Directory connections the pool is increased by.
This parameter specifies the minimum number of Oracle Internet Directory connections in the pool.
This parameter specifies the maximum number of Oracle Internet Directory connections in the pool.
This parameter specifies the time lag (1/100th of a second) permitted before increasing the pool. For example, if the time lag value is 100 it means 1 second. This indicates that if the concurrent connections arrive within 1 second then the server must wait.
This parameter specifies the maximum time in seconds the server has to wait to get a connection after it has reached the maximum number of connections.
This parameter specifies the time after which the server tries to reconnect to Oracle Internet Directory.
This parameter determines which port the listener is listening for the POP service. Selecting Custom enables administrators to specify their own presentation name.
This parameter specifies the log messages level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
Range: 4294967295 (32bits, multi-value)
This parameter specifies the default domain for user login. If the user does not provide a domain when logging in, the value of this parameter is used.
This parameter specifies the maximum number of clients allowed to connect to the server instance.
This parameter specifies the maximum number of times a nesting rule can be applied to a message. In general, setting this parameter to a smaller number increases overall performance, but not for systems that use rules heavily
Enables read messages to be deleted from the server.
Enables all or unread messages to be retrieved from the server. If the parameter is set to all, the server retrieves all mails. If the parameter is set to unread or any other value, the server only retrieves unread messages.
The following is a list of SMTP In server parameters and their definitions:
This parameter specifies the number of Oracle Internet Directory connections the pool is increased by.
This parameter specifies the minimum number of Oracle Internet Directory connections in the pool.
This parameter specifies the maximum number of Oracle Internet Directory connections in the pool.
This parameter specifies the time lag (1/100th of a second) permitted before increasing the pool. For example, if the time lag value is 100 it means 1 second. This indicates that if the concurrent connections arrive within 1 second then the server must wait.
This parameter specifies the maximum time in seconds the server has to wait to get a connection after it has reached the maximum number of connections.
This parameter specifies the time after which the server tries to reconnect to Oracle Internet Directory.
This parameter specifies the time interval, in minutes, to detect spam flooding.
SMTP server signals flooding if the number of messages and connections from a single host exceeds the Spam Max. Flood Count within the Spam Flood Interval.
Turns on anti-spamming checks. If this parameter is not set, all anti-spamming checks are turned off.
Enables domains determined by SMTP Relay Domains Allowed. Anti-spamming check.
This parameter specifies the list of domains and sub-domains to be rejected. Anti-spamming check.
This parameter specifies the list of senders to be rejected. Anti-spamming check
This parameter specifies the list of recipients to be rejected. Anti-spamming check.
This parameter specifies a list of IP addresses to be rejected.
List of IP addresses from which connections are permitted, regardles the criteria.
This parameter specifies a list of allowed domains or subdomains from which mail is received, regardles the criteria.
This parameter specifies the list of domains to relay through. Anti-spamming check.
This parameter rewrites rules for recipients.
This parameter rewrites rules for senders.
This parameter specifies the list of local domains.
This parameter specifies the number of threads the client connection pool is increased by.
This parameter specifies the number of seconds after which an idle thread is cleaned up.
This parameter specifies the minimum number of threads available for client connection handling.
This parameter specifies the maximum number of threads available for client connection handling.
This parameter specifies the presentation name used by the server to register with the Oracle9i listener.
This parameter specifies the log messages level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
Range: 4294967295 (32bits, multi-value)
This parameter specifies the maximum number of clients permitted to connect to the server at one time.
This parameter specifies the maximum number of times a nesting rule can be applied to a message. In general, setting this parameter to a smaller number increases overall performance, but not for systems that use rules heavily
This parameter specifies the number of recipients processed in a single relay delivery attempt.
This parameter, when set, specifies the host where relay messages are sent.
This parameter specifies the maximum number of hops a message can go through.
This parameter specifies the maximum allowed incoming message size in bytes.
If the message has been in the queue less than the SMTP Min. Queue Age, the message is skipped for a delivery attempt.
If the postmaster address is set, a copy of the delivery status notification is sent to it.
When a SMTP server is shutdown it may be in the middle of processing certain messages. When the server is restarted, it looks for messages that are being processed. If the messages remain in the same state for this parameter value interval (in minutes), it assumes that the messages are left over from the previous run and processes them again.
This parameter specifies the maximum time a message can be in the queue.
This parameter determines if the Errors To header is to be used for delivery status notifications.
This parameter specifies the number of SMTP connections the outbound SMTP server caches for future delivery to the same host.
This parameter determines if SMTP authentication is enabled. If mandatory is selected, users must authenticate themselves before sending any messages. If optional is selected, users may authenticate themselves, although the SMTP server will accept the message even if the authentication fails. If none is selected, no authentication is required.
This parameter submits inbound messages without resolving the recipient.
Enables external filter processing if set to true.
This parameter specifies the path for the executable of the external process.
The following is a list of SMTP Out server parameters and their definitions:
This parameter specifies the number of Oracle Internet Directory connections the pool is increased by.
This parameter specifies the minimum number of Oracle Internet Directory connections in the pool.
This parameter specifies the maximum number of Oracle Internet Directory connections in the pool.
This parameter specifies the time lag (1/100th of a second) permitted before increasing the pool. For example, if the time lag value is 100 it means 1 second. This indicates that if the concurrent connections arrive within 1 second then the server must wait.
This parameter specifies the maximum time in seconds the server has to wait to get a connection after it has reached the maximum number of connections.
This parameter specifies the time after which the server tries to reconnect to Oracle Internet Directory.
This parameter specifies how often to detect spam flooding. Anti-spamming check.
SMTP server signals flooding if the number of messages and connections from a single host exceeds the Spam Max. Flood Count parameter within the Spam Flood Interval parameter. Anti-spamming check.
Turns on anti-spamming checks. If this parameter is not set, all anti-spamming checks are turned off.
Enables domains determined by SMTP Relay Domains Allowed. Anti-spamming check.
This parameter rewrites rules for senders. Used only by the SMTP In server.
This parameter specifies the list of local domains. Used only by the SMTP Out server.
This parameter specifies the log messages level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
Range: 4294967295 (32bits, multi-value)
This parameter specifies the maximum number of times a nesting rule can be applied to a message. In general, setting this parameter to a smaller number increases overall performance, but not for systems that use rules heavily
This parameter specifies the number of recipients processed in a single relay delivery attempt.
This parameter, when set, specifies the host where relay messages are sent.
This parameter specifies the maximum number of hops a message can go through.
This parameter specifies the maximum allowed incoming message size in bytes.
If the message has been in the queue less than the SMTP Min. Queue Age, the message is skipped for a delivery attempt.
If the postmaster address is set, a copy of the delivery status notification is sent to it.
When a SMTP server is shutdown it may be in the middle of processing certain messages. When the server is restarted, it looks for messages that are being processed. If the messages remain in the same state for this parameter value interval (in minutes), it assumes that the messages are left over from the previous run and processes them again.
This parameter specifies the maximum time a message can be in the queue.
This parameter determines if the Errors To header is to be used for delivery status notifications.
This parameter specifies the number of SMTP connections the outbound SMTP server caches for future delivery to the same host.
This parameter determines if SMTP authentication is enabled.
Enables external filter processing if set to true.
This parameter specifies the path for the executable of the external process.
The following is a list of housekeeping parameters and their definitions:
This parameter determines whether to run the collection task. The collection task collects or reclaims space taken up by messages that are no longer used by removing the message data. Oracle Corporation recommends scheduling this task to run continuously, to keep up with the rate of messages coming in from outside the server.
This parameter determines whether to run the expiration task. The expiration task expires or deletes messages set to expire on or before the current time according to a timer, by moving such messages to the system trash folder. The expiration timer is a folder attribute and can be set by users. Oracle Corporation recommends running this task only once a day.
This parameter specifies whether to perform Oracle Text index synchronization task. Performing synchronization is essential to content-based searching. Doing it frequently should greatly increase search performance. However when expected rate of incoming message is low, doing it too frequently increases the server load unnecessarily. If content-based searching through Oracle Text is used heavily, it is recommended that a dedicated housekeeping instance should be created for this task with a sleep time of five to ten minutes.
This parameter specifies whether to perform Oracle Text optimization task. Oracle Text optimization improves performance of index synchronization. Without optimization, synchronization performance degrades over time. It is recommended that this task should be done about once per week. A dedicated housekeeping instance should be created with task enabled and a sleep time of 24*7 (168) hours.
This parameter determines whether to run the pruning task. The pruning task clears up message queues and the system trash folder, and marks un-referenced messages for the collection task. Oracle Corporation recommends scheduling this task to run continuously, to keep up with user message deletion activity.
This parameter determines whether to run the tertiary store task. This task archives old messages by moving them to another tablespace, presumably a cheaper and larger storage designed for archiving. Oracle Corporation recommends running this task on a monthly basis.
This parameter specifies the log message level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
Range: 4294967295 (32bits, multi-value)
This parameter specifies the minimum age of messages in number of days, for archiving. If the tertiary storage task is turned on, housekeeping tries to archive messages older than the number of days specified in this parameter. Oracle Corporation recommends setting this parameter to at least 30.
This parameter specifies the maximum number of times a nesting can be applied to a message. In general, setting this parameter to a smaller number increases overall performance, but not for systems that use rules heavily.
This parameter specifies the interval between two consecutive starts of the task processing in hours. If the task takes less than this amount of time to finish, the housekeeping process sleeps for the rest of the duration. If the task takes more time than the amount of sleep time specified, the process does not sleep but instead runs continuously.
The following is a list of list server parameters and their definitions:
This parameter specifies the number of Oracle Internet Directory connections the pool is increased by.
This parameter specifies the current number of Oracle Internet Directory connections in the pool.
This parameter specifies the minimum number of Oracle Internet Directory connections in the pool.
This parameter specifies the maximum number of Oracle Internet Directory connections in the pool.
This parameter specifies the message log level.
This parameter specifies the debug messages level. To enable statistics, set the value to 512.
This parameter specifies the number of messages to be processed simultaneously by the list server.
Range: Any positive number greater than zero.
This parameter specifies the number of threads to be spawned to deliver list server messages to subscribers.
Range: Any positive number greater than zero.
This parameter specifies the number of users that each of the user threads deliver messages to.
Range: Any positive number greater than zero.
This parameter specifies the list of local domains served by the list server process.
This sections provides log file locations for the different servers.
The following specifies the IMAP4 log file locations:
On UNIX:
$ORACLE_HOME/oes/log/<install_name>/imap/<process_id>/<process_id>.log.
On Windows:
%ORACLE_HOME\oes\log\<install_name>\imap\<process_id>\<process_id>.log.
The following specifies the POP3 log file locations:
On UNIX:
$ORACLE_HOME/oes/log/<install_name>/pop/<pid>/<pid>.log
On Windows:
%ORACLE_HOME\oes\log\<install_name>\pop\<pid>\<pid>.log
The following specifies the SMTP In and SMTP Out log file locations:
On UNIX:
$ORACLE_HOME/oes/log/<install_name>/smtp_in/<pid>/<pid>.log $ORACLE_HOME/oes/log/<install_name>/smtp_out/<pid>/<pid>.log
On Windows:
%ORACLE_HOME\oes\log\<install_name>\smtp_in\<pid>/<pid>.log
%ORACLE_HOME\oes\log\<install_name>\smtp_out\<pid>\<pid>.log
The following specifies the housekeeping log file locations:
Mail Store on UNIX:
$ORACLE_HOME/oes/log/collector/<SID>.*/text.log
Mail Store on Windows:
%ORACLE_HOME\oes\log\collector\<SID>.*\text.log
Middle Tier on UNIX:
$ORACLE_HOME/oes/log/<install_name>/gc./<pid>/<pid>.log
Middle Tier on Windows:
%ORACLE_HOME\oes\log\<install_name>\gc.\<pid>\<pid>.log
The following specifies the list server log file locations:
On UNIX
$ORACLE_HOME/oes/log/<install_name>/list/<pid>/<pid>.log
On Windows
%ORACLE_HOME%\oes\log\<install_name>\list\<pid>\<pid>.log
Secure Sockets Layer (SSL), is a protocol used for transmitting private documents over the Internet. SSL works by using a public key to encrypt data that is transferred over the SSL connection. Many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs requiring an SSL connection start with https: instead of http:.
In order for the server to communicate securely with clients, customers must obtain an SSL Server Certificate for their machine and configure their network listener to use that certificate.
See Also::
Chapter 16 of the Oracle Advanced Security Administrator's Guide, for how to use the Wallet Manager to create a wallet and store SSL certificates. |
In the Oracle environment, you can use the Oracle Wallet Manager to create and store certificates and the corresponding private keys securely.
To obtain a certificate, use the Wallet Manager to perform the following steps:
This creates a cwallet.sso file in addition to the ewallet.p12, that is the actual wallet. The files can be found in the following location: /etc/ORACLE/WALLETS/<userid>.
The listener.ora file is updated with the required SSL and non- SSL listening end points for both the IMAP4 and POP3 servers during installation. Users only need to set the wallet location and other optional SSL parameters in the listener.ora and the sqlnet.ora files for the listener to receive SSL connections. This can be done manually or by using the Oracle Network Manager.
Add the following WALLET_LOCATION and SSL_CLIENT_AUTHENTICATION entries in the beginning of the $TNS_ADMIN/listener.ora and $TNS_ADMIN/sqlnet.ora files:
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <Directory path containing the cwallet.sso file>) ) ) SSL_CLIENT_AUTHENTICATION = FALSE
The following is what a typical directory parameter value looks like:
/etc/ORACLE/WALLETS/<userid>
The SSL_CLIENT_AUTHENTICATION parameter should be set to True, if the client needs to be authenticated by the server. This requires clients to present their certificates during the SSL handshake.
See Also::
Chapter 7 of the Oracle Advanced Security Administrator's Guide to set the wallet location using Oracle Network Manager. |
If the SSL_CLIENT_AUTHENTICATION parameter is not set, the default setting is true and clients are required to present a certificate during the SSL handshake. If the intent is only to secure the communication, not to authenticate the client using the certificate, then this parameter should be set to false.
IMAP and POP protocol servers can be configured to use SSL for securely communicating with and authenticating clients. To use the SSL client connections, administrators can configure an existing server instance or create a new instance.
A separate server instance is necessary to use SSL and non SSL connections. One server instance cannot manage both types of connections. By default, server instances are configured to manage non SSL connections only. The default listening end points for both IMAP and POP protocol servers are created in the listener.ora file during installation.
Perform the following steps to configure a SSL server instance:
The Thin Client gives users a simple and fast means to access messages and other self service features through a web browser. A user points their browser to a predetermined URL to log in to their e-mail account. Their inbox is rendered dynamically. The logic to render a user's folders, messages, public directory and personal address book runs at the Oracle9i Application Server web server. The browser acts merely as a keyboard and screen. There is no processing or data storage on the desktop.
The Thin Client provides a standard, out of the box web mail solution, along with a tool kit that can extend and modify the standard solution.
The Thin Client log files are derived from values in the following toolkit.properties file:
The files are placed in toolkit.logdirectory; the filename is
$ORACLE_HOME/um/log/webmail_client/xxxx/text.log
The tool kit provides a framework for easy additions or modifications of simple functionality or presentation of the Thin Client. For example, a deployment can replace the Oracle logo with a different graphic. The tool kit can also enforce aspects of the application such as the availability of basic actions or functionality. This reduces the amount of development effort required to customize a solution for customer specific needs.
Properties are defined in the following directory:
$ORACLE_HOME/j2ee/oc4j_um/config/oc4j.properties
The following line ensures that the Thin Client reads this file into the environment only at startup. This line must not be changed or removed.
ct_env=set
Remove the comment and change this value to point to the SMTP host.
mail.smtp.host=%machinehost%
Remove the comment and change this value to point to the port address for the SMTP service listener. The SMTP server default port 25). This value is seldom changed, except to distribute the load for sending many messages.
mail.smtp.port=25
Set the fully qualified domain name to be appended to addresses that are not fully qualified.
mail.host.qualifiedname=oracle.com
If someone sends an e-mail message to recipient, the Thin Client first attempts to resolve the name from the user's personal address book and other LDAP directories. If the recipient does not exist, the program assumes the message is for someone in the fully qualified domain. This value is appended to recipient and sent. If the mail domain was set to acme.com, recipient would be re-written as recipient@acme.com.
The state file is a XML file that defines the navigation behavior of the Thin Client. This file provides a way to easily define and manage state file transitions in the client. A state transition defines the logic that must be executed by the application when the user moves from one state file to another.
The state file for configuration can be found in the following directory:
toolkit.statefile=%ORACLE_HOME%/um/client/config/statefile.xmll
toolkit.clientdir=/templates/
toolkit.imagedir=/um/images/
toolkit.pagesuffix=.uix
supportedLanguages=en,ar,cs,da,de,el,es,fi,fr,fr_ CA,hu,it,iw,ja,ko,nl,no,pl,pt,pt_BR,ro,ru,sk,sv,th,tr,zh_CN,zh_TW voicemailLanguages=en-GB,da,nl,fr,de,it,es,sv,en-US
Components of the Thin Client application are integrated by a set of tabs visible on every page, enabling easy navigation from one component to another. The following define URLs that tie together parts of the Thin Client applications:
client.admintab.url=/um/DomainManagement.jsp client.preferencestab.url=/um/PFAccountBasicSettings.jsp client.admin.url=/um/DomainManagement.jsp client.preferences.url=/um/PFAccountBasicSettings.jsp client.corporate.url=/um/traffic_cop client.product.url=http://www.oracle.com client.portal.url=http://www.oracle.com client.privacystatement.URL=
client.image.corporate=/um/images/corporateBrand_oracle.gif client.image.product=/um/images/branding_collaborationsuite.gif client.image.portal=/um/images/globalbutton_returntoportal.gif client.image.login=/um/images/globalbutton_login.gif client.image.logout=/um/images/globallogout.gif client.image.preferences=/um/images/globalpreferences.gif client.image.help=/um/images/globalhelp.gif
The Thin Client log files can be found in the following directory:
toolkit.logdirectory=%ORACLE_HOME%/um/log toolkit.logfilename=Webmail_Client toolkit.loghostclient=%machinehost% toolkit.loglevel=error toolkit.debugmode=false