Oracle® Email Administrator's Guide Release 2 (9.0.4.1) Part Number B10720-02 |
|
|
View PDF |
This chapter discusses the different servers and processes of the Oracle Email system.
This chapter contains the following topics:
See Also:
Chapter 5, "Security" for information on virus scrubber |
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.
Using Oracle Enterprise Manager, perform the following steps to modify mail store default parameters:
Table 3-1 lists the mail store parameters.
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.
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.
To start, stop, or reinitialize all server processes, use Oracle Enterprise Manager as follows:
To create a server instance, use Oracle Enterprise Manager as follows:
To create a new server instance with the same parameter values as an existing server instance:
To delete a server instance, use Oracle Enterprise Manager as follows:
To start a server instance, use Oracle Enterprise Manager as follows:
To stop a server instance, use Oracle Enterprise Manager as follows:
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:
All new server instances are created with default parameters for that server type. The default parameters can later be modified for specific server instances.
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:
To modify parameters for a specific service process, use Oracle Enterprise Manager as follows:
Table 3-2 describes the features of these two protocols for retrieving e-mail messages.
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.
See Also:
Chapter 3, "Servers and Processes" for detailed information on IMAP and POP server parameters |
See Also:
"Managing Services and Processes" for instructions on creating, deleting, or setting parameters for IMAP and POP servers |
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.
The flexible architecture of Oracle Email enables users to set up a single or multi-tier configuration appropriate to a site's needs.
A single node setup has one mail store and SMTP server running on the same host, supporting a small numbers of users.
A single mail store setup divides two processes into two tiers:
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.
A multiple mail store setup can have two configurations for multiple mail stores:
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.
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.
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:
Upon receipt of a connection request, a worker thread is picked up from the pool to handle the request and the following occurs:
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 |
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:
SMTP_auth
is turned on, this thread pool is also used for user authentication prior to sending out a message.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.
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.
To execute and complete name resolution, the inbound SMTP process parses each rule for every address in the message envelope during mail delivery.
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
: jsmith@acme.com
in the message, the envelope From
is jsmith@acme.com
.
Similarly, the envelope To
is derived from an incoming message line, such as RCPT TO:
john.smith@acme.com
. The information for envelope To
and envelope From
is stored in a different location from the header.
Mail is routed based solely on the envelope To
data rather than on the message To:
or From:
headers supplied by the sender. These headers contain no significant envelope information and can misrepresent who sent the mail to whom, as is illustrated in Figure 3-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.
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.
HELO acme.org 250 mail.rico.net Hello ernie.com [104.65.21.123], pleased to meet you MAIL FROM: forged-address@acme.org 250 forged-address@acme.org... Sender ok RCPT TO: john.smith@acme.org 250 john.smith@acme.org... Recipient OK DATA 354 Enter mail, end with "." on a line by itself From: another-forged-address@moreover.com To: (your address suppressed for stealth mailing and annoyance) . 250 OAA08757 Message accepted for delivery
Received: from acme.org ([104.128.23.115]) by mail.rico.net (8.8.5) From: another-forged-address@moreover.org To: (your address suppressed for stealth mailing and annoyance)
Notice that the only true data seen by this recipient is in the Received
line, which was taken from the RCPT
TO
entry actually sent. The apparent sending addresses need not have any relationship to the physical facts. They are taken from the data of the envelope From
, message
From:
, and message
To:
lines exactly as entered by the sender, with no necessary relationship to what is factual.
This example illustrates why the From
, From:
, and To:
headers are not reliable in mail, because they can easily be forged.
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.
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:
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.
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.
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.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)
:
Text description of the illustration example2.gif
For example:
john.jones@home.ORG
resolved by the Pattern
(LHS)
rule,
Result (RHS)= john.jones@home.org $* (matches zero or more) = john.jones @ matches exactly $+ (matches one or more) = home
$-
= exactly one token
john
rewritten by rhs $- = ->john
If the result was john@uuhost
, then the rule would not match.
$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.
Oracle Email uses two types of address 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.
The following example takes the From: (sender) and the To: (recipient) addresses and rewrites them using the rewriting rules.
$*@$+.com,$1@uuhost.com, "This changes john.doe@foo.com to john.doe@uuhost.com"
Rule:
@
sign and take the one token after the @
sign with the.com
at the end and change it.$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 john.doe@uuhost.com
as the sender of the message. It is important to remember that the header information is never changed from its original entries.
$*.$*@uuhost,$1.$2@foo.com, "This changes fred.jones@uuhost to fred.jones@foo.com"
Rule:
uuhost
after the @
sign.$1
and $2
respectively, and keep a period (.) between them.@
sign, replace uuhost
with foo.com
.The following example shows how to rewrite an e-mail address using fred.jones@uuhost
. The address points to uuhost
which is a Unix to Unix copy (UUCP) system name. The message is sent using the UUCP software which requires the address form of uuhost!username
, and that the current address be rewritten for UUCP. Consider the following example:
$*@uuhost,uuhost!$1,"Changing from to UUCP address"
Using the following rewriting rule, you can change this address to a more compatible Internet address such as fred.jones@foo.com
.
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.
See Also:
Chapter 3, "Servers and Processes" for detailed information on SMTP parameters |
See Also:
"Managing Services and Processes" for instructions on creating, deleting, or setting parameters for SMTP servers |
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.
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:
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 |
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
.
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 |
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. |
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:
For example, if the housekeeper should queue messages for indexing every three minutes, enter 3
in the field.
As an ongoing process, housekeeping periodically collects newly arrived messages to Oracle Text for indexing.
To enable content indexing for a user, perform the following steps:
Document Binary Search
parameter.Text
Synchronization
parameter of the user by selecting Text Only.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.
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:
Create a new Oracle Email housekeeping instance by clicking Create or Create Like.
For example, if the housekeeper should queue messages for indexing every three minutes, enter 3
in the field.
This ongoing housekeeper process wakes up periodically to clean up the Oracle Text index.
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 |
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:
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 |
Perform the following steps to move the ESTERSTORE
tablespace after Oracle Email has already been installed:
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
ESTERSTORE
tablespace offline.
alter tablespace esterstore offline normal;
ESTERSTORE
tablespace using the operating system to a different diskALTER
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;
ESTERSTORE
tablespace online.
alter tablespace esterstore online;
After the ESTERSTORE
tablespace has been created, enable tertiary storage for an instance of Oracle Email housekeeper using the following steps:
Tertiary
Store
parameter to Enable.For example, if the housekeeping process performs tertiary storage every week, enter 10080 (60*24*7).
For example, if you enter 60 in this field, messages that are 60 days old are moved to tertiary storage.
The housekeeping server periodically moves messages of the appropriate age into tertiary storage.
See Also:
Chapter 3, "Servers and Processes" for detailed information on housekeeping parameters |
See Also:
"Managing Services and Processes" for instructions on creating, deleting, or setting parameters for housekeeping |
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 |
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 include
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:
Subscription type controls who can subscribe to a list.
Table 3-9 describes the list posting type, which can restrict non-members' postings.
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. |
Table 3-10 describes the list parameters.
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 test@acme.com
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
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"
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 abc@foo.com
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 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.
The following is an example of how to create the get_cust_list
PL/SQL procedure.
cust_list@acme.com
.External procedure
parameter to get_cust_list
.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 cust_list@acme.com
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.
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 cust_list@acme.com
using an Oracle Email SMTP server delivers the mail to all the recipients in the customer_list
table.
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.
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>. ...
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:
all_emp@acme.com
.Group
merge
tag
parameter to mail merge.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.
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 all_emp@acme.com
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 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>
If TZH
and TZM
are not specified, the list server uses the sender's time zone to schedule delivery of the mail.
Using Oracle Webmail, you can
To create a list, perform the following steps:
>
Distribution List Management >
Create a new list.To edit list properties, perform the following steps:
>
Distribution List Management >
Edit list properties.To modify domain preferences for lists, perform the following steps:
>
Default New List.Perform the following steps to delete a list:
To delete a list, perform the following steps:
>
Distribution List Management >
Delete list(s).To view all lists in a particular domain, perform the following steps:
>
Distribution List Management >
Show list(s).To show list members, perform the following steps:
>
Membership Management >
Show Members.To add or delete list members, perform the following steps:
>
Membership Management >
Add/Remove Members.To show all the lists subscribed to by a user, perform the following steps:
>
Miscellaneous Functions >
Show all memberships of a user.See Also:
Chapter 3, "Servers and Processes" for detailed information on list server parameters |
See Also:
"Managing Services and Processes" for instructions on creating, deleting, or setting parameters for list servers |
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.
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.
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.
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.
There are two types of newsgroup exchanges, which are known as feeds:
The processes required for NNTP service are shared between the inbound and outbound servers.
The NNTP inbound server has two functions:
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.
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.
Table 3-15 describes the peer server parameters in alphabetical order.
You can use Oracle Webmail to add, edit, or delete peer servers, as the following sections describe.
To add a peer server, perform the following steps:
>
Peer Server Management.To edit a peer server, perform the following steps:
>
Peer Server Management.To delete a peer server, perform the following steps:
>
Peer Server Management.See Also:
Chapter 8, "Parameters and Log Files" for detailed information on NNTP server parameters |
See Also:
"Managing Services and Processes" for instructions on creating, deleting, or setting parameters for NNTP servers |
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:
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:
Table 3-16 describes the newsgroup parameters in alphabetical order.
You can use the Oracle Webmail client to add, edit, or delete private and public newsgroups.
To add a private newsgroup, perform the following steps:
>
Private Newsgroup Management.To edit a private newsgroup, perform the following steps:
>
Private Newsgroup Management.To delete a private newsgroup, perform the following steps:
>
Public Newsgroup Management.To add a public newsgroup, perform the following steps:
>
Public Newsgroup Management.To edit a public newsgroup, perform the following steps:
>
Public Newsgroup Management.To delete a public newsgroup, perform the following steps: